<!DOCTYPE html>
<!-- saved from url=(0127)https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub -->
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>WebPerf WG @ TPAC 2018</title><link rel="shortcut icon" href="https://ssl.gstatic.com/docs/documents/images/kix-favicon7.ico"><meta name="referrer" content="strict-origin-when-cross-origin"><style type="text/css" nonce="">
      @import url("https://fonts.googleapis.com/css?family=Google+Sans");
      @import url("https://fonts.googleapis.com/css?family=Roboto");

      body {
        font-family: Roboto, arial, sans, sans-serif;
        margin: 0;
      }

      iframe {
        border: 0;
        frameborder: 0;
        height: 100%;
        width: 100%;
      }

      #header {
        align-items: center;
        background: white;
        border-bottom: 1px #ccc solid;
        display: flex;
        height: 60px;
        justify-content: space-between;
        position: fixed;
        top: 0;
        width: 100%;
        z-index: 100;
      }

      #header #title {
        font-family: 'Google Sans';
        font-size: large;
        margin: auto 0 auto 20px;
        overflow: hidden;
        text-overflow: ellipsis;
        white-space: nowrap;
        width: 70%;
      }

      #header #interval {
        margin: auto 25px auto 0;
        font-family: Roboto;
        font-size: small;;
      }

      #footer {
        background: #f0f0f0;
        border-bottom: 1px #ccc solid;
        bottom: 0;
        font-family: Roboto;
        font-size: small;
        padding: 10px 10px;
        position: fixed;
        text-align: center;
        width: 100%;
      }

      #contents {
        padding: 100px 20% 50px 20%;
      }

      @media only screen and (max-device-width: 800px) {
        #header {
          border-bottom-width: 5px;
          height: auto;
          display: block;
        }

        #header #title {
          font-size: 3em;
          margin: auto 0 auto 20px;
          width: 90%;
        }

        #header #interval {
          font-size: 1.5em;
          margin: 10px 0 auto 25px;
        }

        #contents {
          padding: 150px 5% 80px;
        }

        #footer {
          font-size: 2em;
        }
      }

      .dash {
        padding: 0 6px;
      }
    </style></head><body><div id="header"><div id="title">WebPerf WG @ TPAC 2018</div><div id="interval"><span></span></div></div><div id="contents"><style type="text/css">.lst-kix_sxeerzeb0rg-6>li:before{content:"\0025cf  "}.lst-kix_sxeerzeb0rg-7>li:before{content:"\0025cb  "}.lst-kix_o0y39f1jde3c-6>li:before{content:"-  "}.lst-kix_sxeerzeb0rg-3>li:before{content:"\0025cf  "}.lst-kix_o0y39f1jde3c-7>li:before{content:"-  "}.lst-kix_o0y39f1jde3c-8>li:before{content:"-  "}.lst-kix_sxeerzeb0rg-4>li:before{content:"\0025cb  "}.lst-kix_sxeerzeb0rg-5>li:before{content:"\0025a0  "}.lst-kix_ctpmn3svt5dw-6>li:before{content:"\0025cf  "}ul.lst-kix_ceulq9qdp9ut-8{list-style-type:none}ul.lst-kix_ceulq9qdp9ut-7{list-style-type:none}.lst-kix_ctpmn3svt5dw-7>li:before{content:"\0025cb  "}ul.lst-kix_ceulq9qdp9ut-6{list-style-type:none}ul.lst-kix_ceulq9qdp9ut-5{list-style-type:none}.lst-kix_ctpmn3svt5dw-8>li:before{content:"\0025a0  "}.lst-kix_sxeerzeb0rg-8>li:before{content:"\0025a0  "}ul.lst-kix_kolajlgg2iz3-7{list-style-type:none}ul.lst-kix_kolajlgg2iz3-6{list-style-type:none}ul.lst-kix_kolajlgg2iz3-8{list-style-type:none}.lst-kix_o0y39f1jde3c-0>li:before{content:"-  "}.lst-kix_ctpmn3svt5dw-5>li:before{content:"\0025a0  "}.lst-kix_ctpmn3svt5dw-4>li:before{content:"\0025cb  "}.lst-kix_o0y39f1jde3c-2>li:before{content:"-  "}.lst-kix_o0y39f1jde3c-1>li:before{content:"-  "}.lst-kix_o0y39f1jde3c-3>li:before{content:"-  "}.lst-kix_ctpmn3svt5dw-2>li:before{content:"\0025a0  "}.lst-kix_ctpmn3svt5dw-3>li:before{content:"\0025cf  "}.lst-kix_ctpmn3svt5dw-0>li:before{content:"\0025cf  "}.lst-kix_sxeerzeb0rg-2>li:before{content:"\0025a0  "}ul.lst-kix_kolajlgg2iz3-1{list-style-type:none}.lst-kix_o0y39f1jde3c-5>li:before{content:"-  "}ul.lst-kix_kolajlgg2iz3-0{list-style-type:none}ul.lst-kix_kolajlgg2iz3-3{list-style-type:none}.lst-kix_o0y39f1jde3c-4>li:before{content:"-  "}ul.lst-kix_kolajlgg2iz3-2{list-style-type:none}.lst-kix_sxeerzeb0rg-0>li:before{content:"\0025cf  "}.lst-kix_sxeerzeb0rg-1>li:before{content:"\0025cb  "}ul.lst-kix_kolajlgg2iz3-5{list-style-type:none}.lst-kix_ctpmn3svt5dw-1>li:before{content:"\0025cb  "}ul.lst-kix_kolajlgg2iz3-4{list-style-type:none}.lst-kix_hj1iazp81ndn-0>li:before{content:"-  "}.lst-kix_hj1iazp81ndn-1>li:before{content:"-  "}ul.lst-kix_n1vgv7b27bdi-8{list-style-type:none}ul.lst-kix_n1vgv7b27bdi-6{list-style-type:none}ul.lst-kix_n1vgv7b27bdi-7{list-style-type:none}ul.lst-kix_n1vgv7b27bdi-4{list-style-type:none}ul.lst-kix_n1vgv7b27bdi-5{list-style-type:none}ul.lst-kix_n1vgv7b27bdi-2{list-style-type:none}ul.lst-kix_n1vgv7b27bdi-3{list-style-type:none}ul.lst-kix_n1vgv7b27bdi-0{list-style-type:none}ul.lst-kix_n1vgv7b27bdi-1{list-style-type:none}.lst-kix_hj1iazp81ndn-8>li:before{content:"-  "}.lst-kix_hj1iazp81ndn-4>li:before{content:"-  "}.lst-kix_hj1iazp81ndn-2>li:before{content:"-  "}.lst-kix_hj1iazp81ndn-6>li:before{content:"-  "}ul.lst-kix_4a8urx38ygu2-2{list-style-type:none}ul.lst-kix_4a8urx38ygu2-1{list-style-type:none}ul.lst-kix_4a8urx38ygu2-4{list-style-type:none}ul.lst-kix_4a8urx38ygu2-3{list-style-type:none}ul.lst-kix_4a8urx38ygu2-6{list-style-type:none}ul.lst-kix_4a8urx38ygu2-5{list-style-type:none}ul.lst-kix_4a8urx38ygu2-8{list-style-type:none}ul.lst-kix_4a8urx38ygu2-7{list-style-type:none}ul.lst-kix_sxeerzeb0rg-0{list-style-type:none}ul.lst-kix_sxeerzeb0rg-1{list-style-type:none}ul.lst-kix_sxeerzeb0rg-4{list-style-type:none}ul.lst-kix_sxeerzeb0rg-5{list-style-type:none}.lst-kix_4a8urx38ygu2-4>li:before{content:"-  "}.lst-kix_4a8urx38ygu2-8>li:before{content:"-  "}ul.lst-kix_sxeerzeb0rg-2{list-style-type:none}.lst-kix_l826szjijzgg-0>li:before{content:"\0025cf  "}.lst-kix_l826szjijzgg-4>li:before{content:"\0025cb  "}ul.lst-kix_sxeerzeb0rg-3{list-style-type:none}ul.lst-kix_sxeerzeb0rg-8{list-style-type:none}ul.lst-kix_sxeerzeb0rg-6{list-style-type:none}ul.lst-kix_sxeerzeb0rg-7{list-style-type:none}ul.lst-kix_4a8urx38ygu2-0{list-style-type:none}.lst-kix_4a8urx38ygu2-6>li:before{content:"-  "}.lst-kix_l826szjijzgg-2>li:before{content:"\0025a0  "}.lst-kix_4a8urx38ygu2-0>li:before{content:"-  "}.lst-kix_4a8urx38ygu2-2>li:before{content:"-  "}.lst-kix_t7nnjunjipyj-5>li:before{content:"\0025a0  "}.lst-kix_t7nnjunjipyj-6>li:before{content:"\0025cf  "}.lst-kix_l826szjijzgg-8>li:before{content:"\0025a0  "}.lst-kix_t7nnjunjipyj-1>li:before{content:"\0025cb  "}.lst-kix_l826szjijzgg-5>li:before{content:"\0025a0  "}.lst-kix_t7nnjunjipyj-2>li:before{content:"\0025a0  "}.lst-kix_uphsdgtdp5ob-2>li:before{content:"\0025a0  "}.lst-kix_uphsdgtdp5ob-3>li:before{content:"\0025cf  "}.lst-kix_uphsdgtdp5ob-7>li:before{content:"\0025cb  "}.lst-kix_bwd3jdjd8i8o-8>li:before{content:"\0025a0  "}.lst-kix_uphsdgtdp5ob-6>li:before{content:"\0025cf  "}.lst-kix_bwd3jdjd8i8o-5>li:before{content:"\0025a0  "}ul.lst-kix_6bh46ir5vr6z-0{list-style-type:none}.lst-kix_2bexye2j2yhs-7>li:before{content:"\0025cb  "}.lst-kix_bwd3jdjd8i8o-0>li:before{content:"\0025cf  "}.lst-kix_ceulq9qdp9ut-2>li:before{content:"-  "}ul.lst-kix_6bh46ir5vr6z-2{list-style-type:none}ul.lst-kix_6bh46ir5vr6z-1{list-style-type:none}.lst-kix_2bexye2j2yhs-8>li:before{content:"\0025a0  "}.lst-kix_bwd3jdjd8i8o-1>li:before{content:"\0025cb  "}.lst-kix_2bexye2j2yhs-3>li:before{content:"\0025cf  "}.lst-kix_bwd3jdjd8i8o-4>li:before{content:"\0025cb  "}.lst-kix_ceulq9qdp9ut-6>li:before{content:"-  "}.lst-kix_2bexye2j2yhs-4>li:before{content:"\0025cb  "}.lst-kix_ceulq9qdp9ut-7>li:before{content:"-  "}ul.lst-kix_6bh46ir5vr6z-8{list-style-type:none}ul.lst-kix_6bh46ir5vr6z-7{list-style-type:none}ul.lst-kix_bwd3jdjd8i8o-0{list-style-type:none}.lst-kix_7gx7dxrc3itt-8>li:before{content:"\0025a0  "}ul.lst-kix_6bh46ir5vr6z-4{list-style-type:none}.lst-kix_3c75qjtfhdqa-7>li:before{content:"\0025cb  "}ul.lst-kix_6bh46ir5vr6z-3{list-style-type:none}.lst-kix_ceulq9qdp9ut-3>li:before{content:"-  "}ul.lst-kix_6bh46ir5vr6z-6{list-style-type:none}ul.lst-kix_6bh46ir5vr6z-5{list-style-type:none}ul.lst-kix_bwd3jdjd8i8o-6{list-style-type:none}.lst-kix_iq68aatvclj5-5>li:before{content:"\0025a0  "}ul.lst-kix_bwd3jdjd8i8o-5{list-style-type:none}ul.lst-kix_bwd3jdjd8i8o-8{list-style-type:none}ul.lst-kix_bwd3jdjd8i8o-7{list-style-type:none}ul.lst-kix_bwd3jdjd8i8o-2{list-style-type:none}ul.lst-kix_bwd3jdjd8i8o-1{list-style-type:none}ul.lst-kix_bwd3jdjd8i8o-4{list-style-type:none}.lst-kix_3c75qjtfhdqa-2>li:before{content:"\0025a0  "}.lst-kix_3c75qjtfhdqa-6>li:before{content:"\0025cf  "}ul.lst-kix_bwd3jdjd8i8o-3{list-style-type:none}.lst-kix_7gx7dxrc3itt-5>li:before{content:"\0025a0  "}.lst-kix_7gx7dxrc3itt-4>li:before{content:"\0025cb  "}.lst-kix_3c75qjtfhdqa-3>li:before{content:"\0025cf  "}.lst-kix_iq68aatvclj5-6>li:before{content:"\0025cf  "}.lst-kix_7gx7dxrc3itt-1>li:before{content:"\0025cb  "}.lst-kix_2bexye2j2yhs-0>li:before{content:"\0025cf  "}.lst-kix_iq68aatvclj5-1>li:before{content:"\0025cb  "}.lst-kix_7gx7dxrc3itt-0>li:before{content:"\0025cf  "}.lst-kix_iq68aatvclj5-2>li:before{content:"\0025a0  "}ul.lst-kix_ctpmn3svt5dw-0{list-style-type:none}ul.lst-kix_ctpmn3svt5dw-1{list-style-type:none}ul.lst-kix_ctpmn3svt5dw-2{list-style-type:none}ul.lst-kix_f7h74n3bgwey-3{list-style-type:none}ul.lst-kix_ctpmn3svt5dw-3{list-style-type:none}ul.lst-kix_f7h74n3bgwey-2{list-style-type:none}ul.lst-kix_ctpmn3svt5dw-4{list-style-type:none}ul.lst-kix_f7h74n3bgwey-1{list-style-type:none}ul.lst-kix_ctpmn3svt5dw-5{list-style-type:none}ul.lst-kix_f7h74n3bgwey-0{list-style-type:none}ul.lst-kix_ctpmn3svt5dw-6{list-style-type:none}ul.lst-kix_f7h74n3bgwey-7{list-style-type:none}ul.lst-kix_ctpmn3svt5dw-7{list-style-type:none}ul.lst-kix_f7h74n3bgwey-6{list-style-type:none}ul.lst-kix_ctpmn3svt5dw-8{list-style-type:none}ul.lst-kix_f7h74n3bgwey-5{list-style-type:none}ul.lst-kix_f7h74n3bgwey-4{list-style-type:none}ul.lst-kix_f7h74n3bgwey-8{list-style-type:none}.lst-kix_cfaanro8u333-4>li:before{content:"-  "}.lst-kix_cfaanro8u333-8>li:before{content:"-  "}.lst-kix_hj1iazp81ndn-7>li:before{content:"-  "}.lst-kix_nr9u9ak7u2vs-2>li:before{content:"-  "}.lst-kix_hj1iazp81ndn-3>li:before{content:"-  "}.lst-kix_nr9u9ak7u2vs-6>li:before{content:"-  "}ul.lst-kix_o0y39f1jde3c-8{list-style-type:none}ul.lst-kix_o0y39f1jde3c-7{list-style-type:none}ul.lst-kix_o0y39f1jde3c-2{list-style-type:none}ul.lst-kix_o0y39f1jde3c-1{list-style-type:none}ul.lst-kix_o0y39f1jde3c-0{list-style-type:none}ul.lst-kix_o0y39f1jde3c-6{list-style-type:none}ul.lst-kix_o0y39f1jde3c-5{list-style-type:none}ul.lst-kix_o0y39f1jde3c-4{list-style-type:none}ul.lst-kix_o0y39f1jde3c-3{list-style-type:none}.lst-kix_l826szjijzgg-1>li:before{content:"\0025cb  "}.lst-kix_zh0nci4hy07-1>li:before{content:"\0025cb  "}.lst-kix_cfaanro8u333-0>li:before{content:"-  "}.lst-kix_4a8urx38ygu2-7>li:before{content:"-  "}ul.lst-kix_zh0nci4hy07-3{list-style-type:none}.lst-kix_zh0nci4hy07-5>li:before{content:"\0025a0  "}ul.lst-kix_zh0nci4hy07-4{list-style-type:none}ul.lst-kix_zh0nci4hy07-5{list-style-type:none}ul.lst-kix_zh0nci4hy07-6{list-style-type:none}ul.lst-kix_zh0nci4hy07-0{list-style-type:none}ul.lst-kix_zh0nci4hy07-1{list-style-type:none}ul.lst-kix_zh0nci4hy07-2{list-style-type:none}.lst-kix_4a8urx38ygu2-3>li:before{content:"-  "}ul.lst-kix_zh0nci4hy07-7{list-style-type:none}ul.lst-kix_zh0nci4hy07-8{list-style-type:none}.lst-kix_f7h74n3bgwey-3>li:before{content:"\0025cf  "}.lst-kix_f7h74n3bgwey-4>li:before{content:"\0025cb  "}.lst-kix_f7h74n3bgwey-5>li:before{content:"\0025a0  "}.lst-kix_f7h74n3bgwey-6>li:before{content:"\0025cf  "}.lst-kix_kolajlgg2iz3-5>li:before{content:"-  "}.lst-kix_f7h74n3bgwey-7>li:before{content:"\0025cb  "}.lst-kix_kolajlgg2iz3-6>li:before{content:"-  "}.lst-kix_f7h74n3bgwey-8>li:before{content:"\0025a0  "}.lst-kix_kolajlgg2iz3-4>li:before{content:"-  "}.lst-kix_kolajlgg2iz3-3>li:before{content:"-  "}.lst-kix_kolajlgg2iz3-1>li:before{content:"-  "}.lst-kix_kolajlgg2iz3-2>li:before{content:"-  "}.lst-kix_kolajlgg2iz3-0>li:before{content:"-  "}.lst-kix_60d2jr3xce8v-1>li:before{content:"-  "}.lst-kix_60d2jr3xce8v-3>li:before{content:"-  "}.lst-kix_6bh46ir5vr6z-8>li:before{content:"\0025a0  "}.lst-kix_60d2jr3xce8v-0>li:before{content:"-  "}.lst-kix_60d2jr3xce8v-4>li:before{content:"-  "}.lst-kix_60d2jr3xce8v-2>li:before{content:"-  "}.lst-kix_6bh46ir5vr6z-1>li:before{content:"\0025cb  "}.lst-kix_6bh46ir5vr6z-0>li:before{content:"\0025cf  "}ul.lst-kix_2bexye2j2yhs-8{list-style-type:none}.lst-kix_60d2jr3xce8v-8>li:before{content:"-  "}.lst-kix_60d2jr3xce8v-5>li:before{content:"-  "}.lst-kix_60d2jr3xce8v-7>li:before{content:"-  "}.lst-kix_n1vgv7b27bdi-0>li:before{content:"\0025cf  "}.lst-kix_60d2jr3xce8v-6>li:before{content:"-  "}.lst-kix_n1vgv7b27bdi-2>li:before{content:"\0025a0  "}.lst-kix_n1vgv7b27bdi-4>li:before{content:"\0025cb  "}.lst-kix_n1vgv7b27bdi-1>li:before{content:"\0025cb  "}.lst-kix_n1vgv7b27bdi-5>li:before{content:"\0025a0  "}ul.lst-kix_2bexye2j2yhs-6{list-style-type:none}ul.lst-kix_2bexye2j2yhs-7{list-style-type:none}ul.lst-kix_2bexye2j2yhs-4{list-style-type:none}ul.lst-kix_2bexye2j2yhs-5{list-style-type:none}ul.lst-kix_2bexye2j2yhs-2{list-style-type:none}ul.lst-kix_2bexye2j2yhs-3{list-style-type:none}ul.lst-kix_2bexye2j2yhs-0{list-style-type:none}ul.lst-kix_2bexye2j2yhs-1{list-style-type:none}.lst-kix_n1vgv7b27bdi-3>li:before{content:"\0025cf  "}.lst-kix_6bh46ir5vr6z-2>li:before{content:"\0025a0  "}.lst-kix_6bh46ir5vr6z-3>li:before{content:"\0025cf  "}.lst-kix_6bh46ir5vr6z-4>li:before{content:"\0025cb  "}.lst-kix_f7h74n3bgwey-2>li:before{content:"\0025a0  "}.lst-kix_6bh46ir5vr6z-6>li:before{content:"\0025cf  "}.lst-kix_f7h74n3bgwey-1>li:before{content:"\0025cb  "}.lst-kix_6bh46ir5vr6z-5>li:before{content:"\0025a0  "}.lst-kix_6bh46ir5vr6z-7>li:before{content:"\0025cb  "}.lst-kix_n1vgv7b27bdi-6>li:before{content:"\0025cf  "}.lst-kix_n1vgv7b27bdi-8>li:before{content:"\0025a0  "}.lst-kix_f7h74n3bgwey-0>li:before{content:"\0025cf  "}.lst-kix_n1vgv7b27bdi-7>li:before{content:"\0025cb  "}.lst-kix_nr9u9ak7u2vs-1>li:before{content:"-  "}.lst-kix_cfaanro8u333-3>li:before{content:"-  "}.lst-kix_cfaanro8u333-5>li:before{content:"-  "}.lst-kix_cfaanro8u333-7>li:before{content:"-  "}.lst-kix_nr9u9ak7u2vs-3>li:before{content:"-  "}.lst-kix_nr9u9ak7u2vs-5>li:before{content:"-  "}.lst-kix_nr9u9ak7u2vs-7>li:before{content:"-  "}.lst-kix_zh0nci4hy07-8>li:before{content:"\0025a0  "}.lst-kix_kolajlgg2iz3-7>li:before{content:"-  "}.lst-kix_cfaanro8u333-1>li:before{content:"-  "}.lst-kix_zh0nci4hy07-0>li:before{content:"\0025cf  "}ul.lst-kix_t7nnjunjipyj-4{list-style-type:none}ul.lst-kix_hj1iazp81ndn-3{list-style-type:none}ul.lst-kix_t7nnjunjipyj-3{list-style-type:none}ul.lst-kix_hj1iazp81ndn-4{list-style-type:none}ul.lst-kix_t7nnjunjipyj-6{list-style-type:none}ul.lst-kix_hj1iazp81ndn-5{list-style-type:none}ul.lst-kix_t7nnjunjipyj-5{list-style-type:none}ul.lst-kix_hj1iazp81ndn-6{list-style-type:none}ul.lst-kix_t7nnjunjipyj-0{list-style-type:none}ul.lst-kix_hj1iazp81ndn-0{list-style-type:none}.lst-kix_zh0nci4hy07-2>li:before{content:"\0025a0  "}.lst-kix_zh0nci4hy07-6>li:before{content:"\0025cf  "}ul.lst-kix_t7nnjunjipyj-2{list-style-type:none}ul.lst-kix_hj1iazp81ndn-1{list-style-type:none}ul.lst-kix_t7nnjunjipyj-1{list-style-type:none}ul.lst-kix_hj1iazp81ndn-2{list-style-type:none}ul.lst-kix_t7nnjunjipyj-8{list-style-type:none}ul.lst-kix_hj1iazp81ndn-7{list-style-type:none}ul.lst-kix_t7nnjunjipyj-7{list-style-type:none}ul.lst-kix_hj1iazp81ndn-8{list-style-type:none}.lst-kix_zh0nci4hy07-4>li:before{content:"\0025cb  "}.lst-kix_t7nnjunjipyj-7>li:before{content:"\0025cb  "}.lst-kix_t7nnjunjipyj-8>li:before{content:"\0025a0  "}ul.lst-kix_uphsdgtdp5ob-5{list-style-type:none}ul.lst-kix_uphsdgtdp5ob-4{list-style-type:none}.lst-kix_t7nnjunjipyj-0>li:before{content:"\0025cf  "}ul.lst-kix_uphsdgtdp5ob-7{list-style-type:none}ul.lst-kix_uphsdgtdp5ob-6{list-style-type:none}ul.lst-kix_uphsdgtdp5ob-1{list-style-type:none}ul.lst-kix_uphsdgtdp5ob-0{list-style-type:none}ul.lst-kix_uphsdgtdp5ob-3{list-style-type:none}ul.lst-kix_uphsdgtdp5ob-2{list-style-type:none}.lst-kix_l826szjijzgg-6>li:before{content:"\0025cf  "}.lst-kix_t7nnjunjipyj-3>li:before{content:"\0025cf  "}.lst-kix_t7nnjunjipyj-4>li:before{content:"\0025cb  "}.lst-kix_l826szjijzgg-7>li:before{content:"\0025cb  "}ul.lst-kix_uphsdgtdp5ob-8{list-style-type:none}.lst-kix_uphsdgtdp5ob-0>li:before{content:"\0025cf  "}.lst-kix_uphsdgtdp5ob-1>li:before{content:"\0025cb  "}.lst-kix_uphsdgtdp5ob-4>li:before{content:"\0025cb  "}.lst-kix_bwd3jdjd8i8o-7>li:before{content:"\0025cb  "}.lst-kix_uphsdgtdp5ob-8>li:before{content:"\0025a0  "}.lst-kix_uphsdgtdp5ob-5>li:before{content:"\0025a0  "}.lst-kix_bwd3jdjd8i8o-6>li:before{content:"\0025cf  "}.lst-kix_2bexye2j2yhs-6>li:before{content:"\0025cf  "}.lst-kix_ceulq9qdp9ut-1>li:before{content:"-  "}.lst-kix_2bexye2j2yhs-5>li:before{content:"\0025a0  "}.lst-kix_bwd3jdjd8i8o-2>li:before{content:"\0025a0  "}.lst-kix_ceulq9qdp9ut-0>li:before{content:"-  "}.lst-kix_ceulq9qdp9ut-4>li:before{content:"-  "}ul.lst-kix_cfaanro8u333-1{list-style-type:none}ul.lst-kix_cfaanro8u333-2{list-style-type:none}.lst-kix_bwd3jdjd8i8o-3>li:before{content:"\0025cf  "}.lst-kix_ceulq9qdp9ut-5>li:before{content:"-  "}.lst-kix_2bexye2j2yhs-2>li:before{content:"\0025a0  "}ul.lst-kix_cfaanro8u333-0{list-style-type:none}ul.lst-kix_7gx7dxrc3itt-7{list-style-type:none}ul.lst-kix_7gx7dxrc3itt-8{list-style-type:none}ul.lst-kix_7gx7dxrc3itt-5{list-style-type:none}ul.lst-kix_7gx7dxrc3itt-6{list-style-type:none}ul.lst-kix_7gx7dxrc3itt-3{list-style-type:none}ul.lst-kix_cfaanro8u333-7{list-style-type:none}ul.lst-kix_7gx7dxrc3itt-4{list-style-type:none}ul.lst-kix_cfaanro8u333-8{list-style-type:none}ul.lst-kix_7gx7dxrc3itt-1{list-style-type:none}ul.lst-kix_cfaanro8u333-5{list-style-type:none}ul.lst-kix_7gx7dxrc3itt-2{list-style-type:none}ul.lst-kix_cfaanro8u333-6{list-style-type:none}ul.lst-kix_iq68aatvclj5-0{list-style-type:none}ul.lst-kix_cfaanro8u333-3{list-style-type:none}ul.lst-kix_7gx7dxrc3itt-0{list-style-type:none}ul.lst-kix_cfaanro8u333-4{list-style-type:none}.lst-kix_7gx7dxrc3itt-6>li:before{content:"\0025cf  "}.lst-kix_7gx7dxrc3itt-7>li:before{content:"\0025cb  "}.lst-kix_3c75qjtfhdqa-8>li:before{content:"\0025a0  "}.lst-kix_3c75qjtfhdqa-5>li:before{content:"\0025a0  "}ul.lst-kix_nr9u9ak7u2vs-8{list-style-type:none}ul.lst-kix_nr9u9ak7u2vs-7{list-style-type:none}ul.lst-kix_nr9u9ak7u2vs-4{list-style-type:none}ul.lst-kix_nr9u9ak7u2vs-3{list-style-type:none}ul.lst-kix_nr9u9ak7u2vs-6{list-style-type:none}.lst-kix_iq68aatvclj5-4>li:before{content:"\0025cb  "}.lst-kix_iq68aatvclj5-8>li:before{content:"\0025a0  "}ul.lst-kix_nr9u9ak7u2vs-5{list-style-type:none}ul.lst-kix_iq68aatvclj5-3{list-style-type:none}ul.lst-kix_iq68aatvclj5-4{list-style-type:none}ul.lst-kix_iq68aatvclj5-1{list-style-type:none}ul.lst-kix_iq68aatvclj5-2{list-style-type:none}.lst-kix_iq68aatvclj5-7>li:before{content:"\0025cb  "}ul.lst-kix_iq68aatvclj5-7{list-style-type:none}ul.lst-kix_iq68aatvclj5-8{list-style-type:none}.lst-kix_3c75qjtfhdqa-4>li:before{content:"\0025cb  "}ul.lst-kix_iq68aatvclj5-5{list-style-type:none}ul.lst-kix_iq68aatvclj5-6{list-style-type:none}.lst-kix_7gx7dxrc3itt-2>li:before{content:"\0025a0  "}.lst-kix_7gx7dxrc3itt-3>li:before{content:"\0025cf  "}.lst-kix_2bexye2j2yhs-1>li:before{content:"\0025cb  "}ul.lst-kix_3c75qjtfhdqa-1{list-style-type:none}ul.lst-kix_3c75qjtfhdqa-0{list-style-type:none}ul.lst-kix_3c75qjtfhdqa-3{list-style-type:none}.lst-kix_ceulq9qdp9ut-8>li:before{content:"-  "}.lst-kix_iq68aatvclj5-0>li:before{content:"\0025cf  "}ul.lst-kix_3c75qjtfhdqa-2{list-style-type:none}.lst-kix_3c75qjtfhdqa-1>li:before{content:"\0025cb  "}ul.lst-kix_3c75qjtfhdqa-5{list-style-type:none}ul.lst-kix_nr9u9ak7u2vs-0{list-style-type:none}ul.lst-kix_3c75qjtfhdqa-4{list-style-type:none}ul.lst-kix_3c75qjtfhdqa-7{list-style-type:none}ul.lst-kix_nr9u9ak7u2vs-2{list-style-type:none}ul.lst-kix_3c75qjtfhdqa-6{list-style-type:none}ul.lst-kix_nr9u9ak7u2vs-1{list-style-type:none}.lst-kix_iq68aatvclj5-3>li:before{content:"\0025cf  "}ul.lst-kix_3c75qjtfhdqa-8{list-style-type:none}.lst-kix_3c75qjtfhdqa-0>li:before{content:"\0025cf  "}ul.lst-kix_60d2jr3xce8v-8{list-style-type:none}ul.lst-kix_60d2jr3xce8v-5{list-style-type:none}ul.lst-kix_60d2jr3xce8v-4{list-style-type:none}ul.lst-kix_60d2jr3xce8v-7{list-style-type:none}ul.lst-kix_60d2jr3xce8v-6{list-style-type:none}ul.lst-kix_60d2jr3xce8v-1{list-style-type:none}ul.lst-kix_60d2jr3xce8v-0{list-style-type:none}.lst-kix_nr9u9ak7u2vs-0>li:before{content:"-  "}ul.lst-kix_60d2jr3xce8v-3{list-style-type:none}ul.lst-kix_60d2jr3xce8v-2{list-style-type:none}.lst-kix_cfaanro8u333-6>li:before{content:"-  "}ul.lst-kix_l826szjijzgg-4{list-style-type:none}ul.lst-kix_l826szjijzgg-3{list-style-type:none}.lst-kix_nr9u9ak7u2vs-4>li:before{content:"-  "}ul.lst-kix_l826szjijzgg-6{list-style-type:none}ul.lst-kix_l826szjijzgg-5{list-style-type:none}ul.lst-kix_l826szjijzgg-8{list-style-type:none}ul.lst-kix_l826szjijzgg-7{list-style-type:none}.lst-kix_nr9u9ak7u2vs-8>li:before{content:"-  "}ul.lst-kix_l826szjijzgg-0{list-style-type:none}.lst-kix_hj1iazp81ndn-5>li:before{content:"-  "}ul.lst-kix_l826szjijzgg-2{list-style-type:none}ul.lst-kix_l826szjijzgg-1{list-style-type:none}.lst-kix_cfaanro8u333-2>li:before{content:"-  "}.lst-kix_4a8urx38ygu2-5>li:before{content:"-  "}.lst-kix_l826szjijzgg-3>li:before{content:"\0025cf  "}.lst-kix_kolajlgg2iz3-8>li:before{content:"-  "}ul.lst-kix_ceulq9qdp9ut-4{list-style-type:none}ul.lst-kix_ceulq9qdp9ut-3{list-style-type:none}ul.lst-kix_ceulq9qdp9ut-2{list-style-type:none}ul.lst-kix_ceulq9qdp9ut-1{list-style-type:none}ul.lst-kix_ceulq9qdp9ut-0{list-style-type:none}li.li-bullet-0:before{margin-left:-18pt;white-space:nowrap;display:inline-block;min-width:18pt}.lst-kix_zh0nci4hy07-3>li:before{content:"\0025cf  "}.lst-kix_zh0nci4hy07-7>li:before{content:"\0025cb  "}.lst-kix_4a8urx38ygu2-1>li:before{content:"-  "}ol{margin:0;padding:0}table td,table th{padding:0}.c23{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;background-color:#f3f3f3;border-left-style:solid;border-bottom-width:1pt;width:76.5pt;border-top-color:#000000;border-bottom-style:solid}.c43{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;background-color:#f3f3f3;border-left-style:solid;border-bottom-width:1pt;width:468pt;border-top-color:#000000;border-bottom-style:solid}.c31{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;background-color:#f3f3f3;border-left-style:solid;border-bottom-width:1pt;width:69.8pt;border-top-color:#000000;border-bottom-style:solid}.c24{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;background-color:#999999;border-left-style:solid;border-bottom-width:1pt;width:69.8pt;border-top-color:#000000;border-bottom-style:solid}.c27{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;border-left-style:solid;border-bottom-width:1pt;width:61.5pt;border-top-color:#000000;border-bottom-style:solid}.c30{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;border-left-style:solid;border-bottom-width:1pt;width:69pt;border-top-color:#000000;border-bottom-style:solid}.c47{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;border-left-style:solid;border-bottom-width:1pt;width:76.5pt;border-top-color:#000000;border-bottom-style:solid}.c26{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;border-left-style:solid;border-bottom-width:1pt;width:328.5pt;border-top-color:#000000;border-bottom-style:solid}.c11{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;border-left-style:solid;border-bottom-width:1pt;width:329.2pt;border-top-color:#000000;border-bottom-style:solid}.c35{-webkit-text-decoration-skip:none;color:#000000;font-weight:400;text-decoration:underline;vertical-align:baseline;text-decoration-skip-ink:none;font-size:15pt;font-family:"Arial";font-style:normal}.c28{color:#000000;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:20pt;font-family:"Arial";font-style:normal}.c54{padding-top:0pt;padding-bottom:3pt;line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}.c19{color:#000000;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:16pt;font-family:"Arial";font-style:normal}.c32{margin-left:18pt;padding-top:3pt;padding-bottom:0pt;line-height:1.0;orphans:2;widows:2;text-align:left}.c7{color:#000000;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:11pt;font-family:"Trebuchet MS";font-style:normal}.c29{margin-left:18pt;padding-top:3pt;padding-bottom:4pt;line-height:1.0;orphans:2;widows:2;text-align:left}.c0{color:#000000;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:11pt;font-family:"Arial";font-style:normal}.c33{padding-top:20pt;padding-bottom:6pt;line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}.c18{color:#000000;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:11pt;font-family:"Arial";font-style:italic}.c44{color:#000000;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:16pt;font-family:"Arial";font-style:italic}.c6{padding-top:18pt;padding-bottom:6pt;line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}.c14{color:#1155cc;text-decoration:none;vertical-align:baseline;font-size:20pt;font-family:"Arial";font-style:normal}.c1{padding-top:0pt;padding-bottom:0pt;line-height:1.15;orphans:2;widows:2;text-align:left}.c13{color:#000000;text-decoration:none;vertical-align:baseline;font-size:11pt;font-family:"Arial";font-style:normal}.c15{padding-top:4pt;padding-bottom:0pt;line-height:1.0;orphans:2;widows:2;text-align:left}.c51{padding-top:10pt;padding-bottom:0pt;line-height:1.0;orphans:2;widows:2;text-align:left}.c20{color:#000000;text-decoration:none;vertical-align:baseline;font-size:9pt;font-family:"Arial";font-style:normal}.c25{color:#000000;text-decoration:none;vertical-align:baseline;font-size:26pt;font-family:"Arial";font-style:normal}.c50{font-weight:400;vertical-align:baseline;font-size:11pt;font-family:"Arial";font-style:normal}.c48{font-weight:400;text-decoration:none;vertical-align:baseline;font-family:"Arial";font-style:normal}.c16{padding-top:0pt;padding-bottom:0pt;line-height:1.0;text-align:left}.c9{text-decoration-skip-ink:none;-webkit-text-decoration-skip:none;color:#1155cc;text-decoration:underline}.c46{border-spacing:0;border-collapse:collapse;margin-right:auto}.c17{padding-top:0pt;padding-bottom:0pt;line-height:1.0;text-align:center}.c22{background-color:#ffffff;font-size:10.5pt;color:#24292e}.c49{background-color:#ffffff;max-width:468pt;padding:72pt 72pt 72pt 72pt}.c34{background-color:#e2edfe;font-family:"Trebuchet MS";font-weight:400}.c39{font-weight:400;font-family:"Trebuchet MS"}.c4{margin-left:36pt;padding-left:0pt}.c8{color:inherit;text-decoration:inherit}.c52{color:#38761d;text-decoration:none}.c2{margin-left:72pt;padding-left:0pt}.c12{padding:0;margin:0}.c10{margin-left:108pt;padding-left:0pt}.c41{margin-left:144pt;padding-left:0pt}.c36{font-size:9pt}.c53{background-color:#e2edfe}.c37{font-size:15pt}.c38{background-color:#999999}.c42{margin-left:36pt}.c45{height:26pt}.c40{margin-left:72pt}.c3{height:11pt}.c5{font-weight:700}.c21{height:0pt}.title{padding-top:0pt;color:#000000;font-size:26pt;padding-bottom:3pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}.subtitle{padding-top:0pt;color:#666666;font-size:15pt;padding-bottom:16pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}li{color:#000000;font-size:11pt;font-family:"Arial"}p{margin:0;color:#000000;font-size:11pt;font-family:"Arial"}h1{padding-top:20pt;color:#000000;font-size:20pt;padding-bottom:6pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}h2{padding-top:18pt;color:#000000;font-size:16pt;padding-bottom:6pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}h3{padding-top:16pt;color:#434343;font-size:14pt;padding-bottom:4pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}h4{padding-top:14pt;color:#666666;font-size:12pt;padding-bottom:4pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}h5{padding-top:12pt;color:#666666;font-size:11pt;padding-bottom:4pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}h6{padding-top:12pt;color:#666666;font-size:11pt;padding-bottom:4pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;font-style:italic;orphans:2;widows:2;text-align:left}</style><div class="c49"><p class="c54 title" id="h.odc700in1ypg"><span class="c5 c25">WebPerf WG @ TPAC 2018</span></p><p class="c1"><span class="c9 c37"><a class="c8" href="https://www.google.com/url?q=https://bit.ly/webperf-tpac18&amp;sa=D&amp;source=editors&amp;ust=1613252918862000&amp;usg=AOvVaw0Y9UVptsRu-ogjyx658elc">bit.ly/webperf-tpac18</a></span></p><p class="c1 c3"><span class="c0"></span></p><a id="t.6400706949a1901bbe8d65d3299520ba8cabb091"></a><a id="t.0"></a><table class="c46"><tbody><tr class="c21"><td class="c43" colspan="1" rowspan="1"><p class="c16 c3"><span class="c0"></span></p><p class="c15"><span class="c5"><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.wlg3h8rzf61l">Logistics</a></span><span class="c5">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="c5"><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.wlg3h8rzf61l">1</a></span></p><p class="c32"><span><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.dblx6emzzv04">Location &amp; participation</a></span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.dblx6emzzv04">1</a></span></p><p class="c32"><span><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.y0muiebq08s9">Attendees</a></span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.y0muiebq08s9">1</a></span></p><p class="c32"><span><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.8383nmcldg4o">Observers</a></span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.8383nmcldg4o">1</a></span></p><p class="c51"><span class="c5"><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.2wabtvh52huj">Agenda</a></span><span class="c5">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="c5"><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.2wabtvh52huj">2</a></span></p><p class="c32"><span><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.ta3n09kfdtuu">Thursday October 25th - Triage</a></span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.ta3n09kfdtuu">2</a></span></p><p class="c32"><span><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.lomcz4tlryji">Friday October 26th - Design</a></span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.lomcz4tlryji">2</a></span></p><p class="c29"><span><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.ujcl8vybzthn">Design reviews proposals</a></span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span><a class="c8" href="https://docs.google.com/document/d/e/2PACX-1vRdJ0Infp2HBESEk2v_1-2kJAEehQkgExlwJTrqxqrvisx8XLAGRYWQiCBHXXqBDCyl2cNp03rsU09g/pub#h.ujcl8vybzthn">3</a></span></p><p class="c16 c3"><span class="c0"></span></p></td></tr></tbody></table><p class="c1 c3"><span class="c0"></span></p><h1 class="c33" id="h.wlg3h8rzf61l"><span class="c14 c5">Logistics</span></h1><h2 class="c6" id="h.dblx6emzzv04"><span class="c19">Location &amp; participation</span></h2><ul class="c12 lst-kix_zh0nci4hy07-0 start"><li class="c1 c4 li-bullet-0"><span class="c9"><a class="c8" href="https://www.google.com/url?q=http://www.ccc-lyon.com/home&amp;sa=D&amp;source=editors&amp;ust=1613252918865000&amp;usg=AOvVaw2x0VTZAFMjj4fvN5eR3mv3">Cité Centre de Congrès de Lyon</a></span><span class="c0">, 50, quai Charles de Gaulle</span></li><li class="c1 c4 li-bullet-0"><span><b>Remote participation</b>: </span></li></ul><ul class="c12 lst-kix_zh0nci4hy07-1 start"><li class="c1 c2 li-bullet-0"><span class="c5 c13"><b>WebEx Meeting number</b>: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;646 029 056</span></li><li class="c1 c2 li-bullet-0"><span class="c5"><b>Password</b>: click </span><span class="c5"><a class="c8" href="https://www.google.com/url?q=https://lists.w3.org/Archives/Member/w3c-archive/2018Sep/0248.html&amp;sa=D&amp;source=editors&amp;ust=1613252918866000&amp;usg=AOvVaw1HJO8KdVC0h_s1zshz3bQ-">this member-only archive</a></span><span class="c13 c5">&nbsp;or ask the co-chairs</span></li><li class="c1 c2 li-bullet-0"><span class="c5"><a class="c8" href="https://www.google.com/url?q=https://mit.webex.com/mit/j.php?MTID%3Dm0a5775d847ce00e00138429a228cb6d3&amp;sa=D&amp;source=editors&amp;ust=1613252918866000&amp;usg=AOvVaw2zogmDr51niBPEf3q-xZA_">Click to join</a></span><span class="c13 c5">&nbsp;by browser</span></li><li class="c1 c2 li-bullet-0"><span class="c13 c5"><b>Join by phone</b>: +1-617-324-0000,,,646029056#</span></li></ul><p class="c1 c3"><span class="c13 c5"></span></p><p class="c1"><span class="c13 c5">Resources</span></p><ul class="c12 lst-kix_zh0nci4hy07-0"><li class="c1 c4 li-bullet-0"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://www.w3.org/2018/10/TPAC/schedule.html&amp;sa=D&amp;source=editors&amp;ust=1613252918866000&amp;usg=AOvVaw3R9w-Qmcw5IrNVBkQfp75u">TPAC Schedule</a></span></li><li class="c1 c4 li-bullet-0"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://w3c.github.io/charter-webperf/&amp;sa=D&amp;source=editors&amp;ust=1613252918867000&amp;usg=AOvVaw0psX0mLkEsmnavSKHfrRAQ">Web Performance Working Group charter</a></span></li></ul><ul class="c12 lst-kix_zh0nci4hy07-1 start"><li class="c1 c2 li-bullet-0"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/spreadsheets/d/1JIB8c7hfyH_wuxkf6bLgovFekHP1LpTtqBTJGEUIK7E/edit%23gid%3D0&amp;sa=D&amp;source=editors&amp;ust=1613252918867000&amp;usg=AOvVaw3cD_S37sq9amvgjasdirwm">Spec status spreadsheet</a></span></li><li class="c1 c2 li-bullet-0"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/web-platform-tests/labels/wg-webperf&amp;sa=D&amp;source=editors&amp;ust=1613252918868000&amp;usg=AOvVaw0CmvchJAD9WF39-uhoJuL9">WebPerf WPT tests</a></span></li></ul><h2 class="c6" id="h.y0muiebq08s9"><span class="c19">Attendees</span></h2><p class="c1 c3"><span class="c18"></span></p><ul class="c12 lst-kix_sxeerzeb0rg-0 start"><li class="c1 c4 li-bullet-0"><span class="c0">Todd Reifsteck - Microsoft (Thursday, Friday)</span></li><li class="c1 c4 li-bullet-0"><span>Yoav Weiss - Google (Thursday, Friday)</span></li><li class="c1 c4 li-bullet-0"><span>Nicolás Peña Moreno - Google</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Shubhie Panicker - Google</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Tim Dresser - Google</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Garrett Berg - Airbnb</span></li><li class="c1 c4 li-bullet-0"><span>Philip Walton - Google </span><span class="c18">(attending Thursday and Friday, but will probably miss parts of Thursday to attend CSS Houdini)</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Alex Christensen - Apple</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Ryosuke Niwa - Apple (Thursday afternoon; lost Thursday morning for more web components meeting)</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Kinuko Yasuda - Google (Friday, maybe Thursday too but only when I’m not in SW F2F)</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Nate Schloss - Facebook (Friday)</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Benoit Girard - Facebook</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Eric Faust - Facebook</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Andrew Comminos - Facebook</span></li><li class="c1 c4 li-bullet-0"><span>Xiaolu Huang - </span><span class="c22">360 Technology Co., Ltd.</span><span class="c0">(Thursday, Friday)</span></li><li class="c1 c4 li-bullet-0"><span>Bowen Liu - </span><span class="c22">360 Technology Co., Ltd.</span><span>(Thursday, Friday)</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Qingqian Tao - Baidu(Thursday, Friday)</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Addy Osmani - Google (Thursday, pending remote participation)</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Ben Kelly - Google (Friday)</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Xiaoqian Wu - W3C (Thursday, Friday)</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Charles Vazac - Akamai</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Gilles Dubuc - Wikimedia (Thursday, Friday)</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Thomas Steiner - Google (partly on Thursday and Friday)</span></li><li class="c1 c4 li-bullet-0"><span>Nic Jansma - Akamai (Thursday, Friday)</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Weichai Huang - Baidu</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Chris Harrelson - Google</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Markus Stange - Mozilla</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Kouhei Ueno - Google</span></li><li class="c1 c4 li-bullet-0"><span>Douglas Creager - Google (Thursday afternoon, remote)</span></li><li class="c1 c4 li-bullet-0"><span>Makoto Shimazu - Google (Friday)</span></li><li class="c1 c4 li-bullet-0"><span>Matt Falkenhagen - Google</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Marijn Kruisselbrink - Google (Friday)</span></li><li class="c1 c4 li-bullet-0"><span>Surma - Google</span></li></ul><h2 class="c6" id="h.8383nmcldg4o"><span class="c19">Observers</span></h2><p class="c1 c3"><span class="c0"></span></p><ul class="c12 lst-kix_t7nnjunjipyj-0 start"><li class="c1 c4 li-bullet-0"><span class="c0">Thomas McCabe - Squarespace (Thursday, Friday)</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Rob Buis - Igalia (Friday only)</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Yutaka Hirano - Google (Friday)</span></li></ul><p class="c1 c3 c42"><span class="c50 c52"></span></p><p class="c1 c3"><span class="c0"></span></p><h1 class="c33" id="h.2wabtvh52huj"><span class="c5 c14">Agenda</span></h1><h2 class="c6" id="h.ta3n09kfdtuu"><span>Thursday October 25th - </span><span class="c5">Triage</span><span class="c19">&nbsp;</span></h2><p class="c1"><span class="c0">(Overlaps with Houdini and Service Workers)</span></p><p class="c1 c3"><span class="c18"></span></p><a id="t.e14ee8c9c40170660d67c113e7cd2fcbfe5b1105"></a><a id="t.1"></a><table class="c46"><tbody><tr class="c21"><td class="c38 c47" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">Timeslot</span></p></td><td class="c11 c38" colspan="1" rowspan="1"><p class="c16"><span class="c0">Subject</span></p></td><td class="c27 c38" colspan="1" rowspan="1"><p class="c16"><span>Scribe</span></p></td></tr><tr class="c21"><td class="c23" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">8:45~9:00</span></p></td><td class="c11" colspan="1" rowspan="1"><p class="c16"><span class="c0">Intros &amp; agenda review </span></p></td><td class="c27" colspan="1" rowspan="1"><p class="c16 c3"><span class="c0"></span></p></td></tr><tr class="c21"><td class="c23" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">9:00~9:30</span></p></td><td class="c11" colspan="1" rowspan="1"><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1a9atp7wrmzarrlX6dH5nAoX4tU5r9xyXbVSVVKaOCx8/edit%23slide%3Did.g4506d24457_0_0&amp;sa=D&amp;source=editors&amp;ust=1613252918874000&amp;usg=AOvVaw1A669JhwHAolNcWy3OiVnY">Goals and how we get there</a></span></p></td><td class="c27" colspan="1" rowspan="1"><p class="c1"><span class="c0">npm</span></p></td></tr><tr class="c21"><td class="c23" colspan="1" rowspan="1"><p class="c17"><span class="c5 c20">9:30-10:45</span></p></td><td class="c11" colspan="1" rowspan="1"><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/preload/issues?utf8%3D%25E2%259C%2593%26q%3Dis%253Aissue%2Bis%253Aopen%2Blabel%253Adiscuss%2B-milestone%253A%2522Level%2B2%2522&amp;sa=D&amp;source=editors&amp;ust=1613252918875000&amp;usg=AOvVaw1dzrIVjCna4mo2p4XuKdcr">Preload</a></span><span>, </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/resource-hints/issues&amp;sa=D&amp;source=editors&amp;ust=1613252918875000&amp;usg=AOvVaw3P5NXQUn_8DI-tOfVMz11U">Resource Hints</a></span></p></td><td class="c27" colspan="1" rowspan="1"><p class="c1"><span class="c0">xq</span></p></td></tr><tr class="c21"><td class="c23" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">10:45~11:00</span></p></td><td class="c11" colspan="1" rowspan="1"><p class="c1"><span class="c0">Break</span></p></td><td class="c27" colspan="1" rowspan="1"><p class="c1 c3"><span class="c0"></span></p></td></tr><tr class="c21"><td class="c23" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">11:00~12:30</span></p></td><td class="c11" colspan="1" rowspan="1"><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/performance-timeline/milestone/2&amp;sa=D&amp;source=editors&amp;ust=1613252918877000&amp;usg=AOvVaw39plYEs08FXp1pBFSbo2O0">Performance Timeline</a></span><span>, </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues?q%3Dis%253Aopen%2Bis%253Aissue%2Bmilestone%253A%2522Level%2B2%2522%2Blabel%253A%2522requires%2Bgroup%2Bagreement%2522&amp;sa=D&amp;source=editors&amp;ust=1613252918877000&amp;usg=AOvVaw0d8iVKNadSZXEQaOoI02PZ">Resource Timing</a></span><span>, </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues?utf8%3D%25E2%259C%2593%26q%3Dis%253Aissue%2Bis%253Aopen%2B-milestone%253A%2522Level%2B3%2522&amp;sa=D&amp;source=editors&amp;ust=1613252918878000&amp;usg=AOvVaw2Z6gJFQwjKJw9k5_3sUkpF">Navigation Timing L2</a></span></p></td><td class="c27" colspan="1" rowspan="1"><p class="c1 c3"><span class="c0"></span></p></td></tr><tr class="c21"><td class="c23" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">12:30~14:00</span></p></td><td class="c11" colspan="1" rowspan="1"><p class="c1"><span class="c0">Lunch</span></p></td><td class="c27" colspan="1" rowspan="1"><p class="c1 c3"><span class="c0"></span></p></td></tr><tr class="c21"><td class="c23" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">14:00~15:45</span></p></td><td class="c11" colspan="1" rowspan="1"><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/longtasks/issues?q%3Dis%253Aissue%2Bis%253Aopen%2Blabel%253Arequires-discussion&amp;sa=D&amp;source=editors&amp;ust=1613252918879000&amp;usg=AOvVaw2t0kSQ_Ekn87F4ZIot9nRM">Long Tasks</a></span><span>, </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/paint-timing/issues?q%3Dis%253Aissue%2Bis%253Aopen%2Blabel%253A%2522should%2Bdiscuss%2522&amp;sa=D&amp;source=editors&amp;ust=1613252918880000&amp;usg=AOvVaw1MPCEl2m9fDZR0uPq7Cp8J">Paint Timing</a></span><span>, </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/page-visibility/milestone/2&amp;sa=D&amp;source=editors&amp;ust=1613252918880000&amp;usg=AOvVaw3R4tElzqQnMxLpl2LgGtKh">Page Visibility</a></span><span>, </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/requestidlecallback/milestone/1&amp;sa=D&amp;source=editors&amp;ust=1613252918880000&amp;usg=AOvVaw0qoan7KKP8pi6KSyxUODY9">requestIdleCallback</a></span></p></td><td class="c27" colspan="1" rowspan="1"><p class="c1"><span>cvazac</span></p></td></tr><tr class="c45"><td class="c23" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">15:45~16:00</span></p></td><td class="c11" colspan="1" rowspan="1"><p class="c1"><span class="c0">Break</span></p></td><td class="c27" colspan="1" rowspan="1"><p class="c1 c3"><span class="c0"></span></p></td></tr><tr class="c21"><td class="c23" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">16:00~17:30</span></p></td><td class="c11" colspan="1" rowspan="1"><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/network-error-logging/issues/93&amp;sa=D&amp;source=editors&amp;ust=1613252918882000&amp;usg=AOvVaw2M5yqqh95XmxXsxykR-bmJ">NEL</a></span><span>, Reporting</span><span>, </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/server-timing/issues?utf8%3D%25E2%259C%2593%26q%3Dis%253Aissue%2Bis%253Aopen%2B-milestone%253A%2522Level%2B2%2522%2B&amp;sa=D&amp;source=editors&amp;ust=1613252918882000&amp;usg=AOvVaw3WGEIYz0zzAlGADSZMIQJp">Server Timing</a></span><span class="c0">, Distributed Tracing collaboration</span></p></td><td class="c27" colspan="1" rowspan="1"><p class="c1"><span class="c0">tdresser</span></p></td></tr></tbody></table><p class="c1 c3 c40"><span class="c0"></span></p><h2 class="c6" id="h.lomcz4tlryji"><span>Friday October 26th - </span><span class="c5">Design</span></h2><a id="t.0df62066e85e42b831e3822ef8c7b1c457b58372"></a><a id="t.2"></a><table class="c46"><tbody><tr class="c21"><td class="c24" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">Timeslot</span></p></td><td class="c26 c38" colspan="1" rowspan="1"><p class="c16"><span class="c0">Subject</span></p></td><td class="c30 c38" colspan="1" rowspan="1"><p class="c16"><span>Scribe</span></p></td></tr><tr class="c21"><td class="c31" colspan="1" rowspan="1"><p class="c17"><span class="c5 c36">8:45~9:00</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c16"><span>Intros &amp; agenda review </span></p></td><td class="c30" colspan="1" rowspan="1"><p class="c16 c3"><span class="c0"></span></p></td></tr><tr class="c21"><td class="c31" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">9:00~10:45</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/preload/issues?q%3Dis%253Aissue%2Bis%253Aopen%2Blabel%253Adiscuss&amp;sa=D&amp;source=editors&amp;ust=1613252918885000&amp;usg=AOvVaw2s_8Myy89UjQ_e3TVPNI8k">Preload</a></span><span class="c0">&nbsp;(yoav)</span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1pxx3qMLqzcdtJ_o46XLCgE3uCSI0X_jwgqh-subIgWY/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918886000&amp;usg=AOvVaw0dLi-bofE2qtC0i7vYJ5Gl">Input Timing</a></span><span class="c0">&nbsp;(npm)</span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/whatwg/html/pull/4115&amp;sa=D&amp;source=editors&amp;ust=1613252918886000&amp;usg=AOvVaw3RHJdPtHcaypCtWb28eTpU">Prefetch</a></span><span class="c0">&nbsp;(yoav)</span></p></td><td class="c30" colspan="1" rowspan="1"><p class="c1"><span>njansma</span></p></td></tr><tr class="c21"><td class="c31" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">10:45~11:00</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c1"><span class="c0">Break</span></p></td><td class="c30" colspan="1" rowspan="1"><p class="c1 c3"><span class="c0"></span></p></td></tr><tr class="c21"><td class="c31" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">11:00~12:30</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/spanicker/main-thread-scheduling&amp;sa=D&amp;source=editors&amp;ust=1613252918888000&amp;usg=AOvVaw0D3AaudB9kvlpkFDJFp9PS">Scheduling API</a></span><span>&nbsp;- </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/12lkTrTwGedKSFqOFhQTsEdcLI3ydRiAdom_9uQ2FgsM/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918889000&amp;usg=AOvVaw2Ec0-aRO_ug33sYvJoJ5jt">slides</a></span><span>&nbsp;(</span><span>panicker</span><span>)</span></p><p class="c1"><span class="c9">has</span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/tdresser/should-yield/blob/master/README.md&amp;sa=D&amp;source=editors&amp;ust=1613252918889000&amp;usg=AOvVaw0KqRnKr_MHYlMKf2Zjndve">PendingUserInput</a></span><span>&nbsp;- </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1giv9r-2Vy5G8FGAlgBFQU05FlAZKTmp8CF5otFw3QmQ/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918890000&amp;usg=AOvVaw2pyI8SFGiqKBNsPRIs0nYk">slides</a></span><span>&nbsp;(tdresser)</span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/wanderview/fetchevent-worker-timing/blob/master/explainer.md&amp;sa=D&amp;source=editors&amp;ust=1613252918890000&amp;usg=AOvVaw3BiyttobQKbE_Trrulq2uS">FetchEvent Worker Timing</a></span><span>&nbsp;(</span><span>wanderview</span><span>)</span></p></td><td class="c30" colspan="1" rowspan="1"><p class="c1"><span>philipwalton</span></p></td></tr><tr class="c21"><td class="c31" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">12:30~14:00</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c1"><span class="c0">Lunch</span></p></td><td class="c30" colspan="1" rowspan="1"><p class="c1 c3"><span class="c0"></span></p></td></tr><tr class="c21"><td class="c31" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">14:00~15:45</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1gJNE9agv4bvunNkcc8LJeDAxgpdcjJnUedIe3D_RlMY/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918892000&amp;usg=AOvVaw3uyX29yB_aMYC2D5vNf2Iu">In-progress requests</a></span><span class="c0">, (npm)</span></p><p class="c1"><span><b>Scheduling Off Main Thread</b>: </span><span>Task worklet</span><span>&nbsp;- </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/12QX9k2yXFngwbEIm4fA4KJ4HQoiiPa12oBJSisx6FRA/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918892000&amp;usg=AOvVaw0dSnnd-7bJ6htquAsHGZ05">slides</a></span><span>&nbsp;</span><span>&nbsp;(</span><span>panicker</span><span class="c0">)</span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/vdjeric/js-self-profiling&amp;sa=D&amp;source=editors&amp;ust=1613252918893000&amp;usg=AOvVaw2KbRIXfKyofBUplrI1S7Bu">JS profiling</a></span><span>&nbsp;- </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/vdjeric/js-self-profiling/blob/master/doc/tpac-2018-slides.pdf&amp;sa=D&amp;source=editors&amp;ust=1613252918893000&amp;usg=AOvVaw0PA1dKenMPkKynncPoaQPL">slides</a></span><span class="c0">&nbsp;(acomminos)</span></p><p class="c1"><span>Page Prerendering</span><span>&nbsp;- </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1p9rAYi4z4OscjD6Cjx-2KE-Z97IMKq4WTGTCW9fMAYc/edit?usp%3Dsharing&amp;sa=D&amp;source=editors&amp;ust=1613252918893000&amp;usg=AOvVaw1qZNIfeXK5GwiXYbufv-za">slides</a></span><span class="c0">&nbsp;(Qingqian)</span></p></td><td class="c30" colspan="1" rowspan="1"><p class="c1"><span class="c0">Yoav</span></p></td></tr><tr class="c21"><td class="c31" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">15:45~16:00</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c1"><span class="c0">Break</span></p></td><td class="c30" colspan="1" rowspan="1"><p class="c1 c3"><span class="c0"></span></p></td></tr><tr class="c21"><td class="c31" colspan="1" rowspan="1"><p class="c17"><span class="c20 c5">16:00~17:30</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://wicg.github.io/priority-hints/&amp;sa=D&amp;source=editors&amp;ust=1613252918895000&amp;usg=AOvVaw3VyIGnnFIPjc1yFoXhm9c7">Priority Hints</a></span><span class="c0">&nbsp;(yoav)</span></p><p class="c1"><span>Page </span><span>Lifecycle</span><span><b></b>: brief update</span><span>&nbsp;</span><span>- </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1lqWh6rEnC0IqPq0yh7enAvW1LumxjhMdJO9reVI0-28/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918896000&amp;usg=AOvVaw1Hl1QGCojcodZvDDFwjQJx">slides</a></span><span>&nbsp;</span><span class="c0">(panicker)</span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1lyzjzzQVw6iY9kAiAxNCDVuwF6Ralo2iOS0D6LlgH2Y/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918896000&amp;usg=AOvVaw2lYFqwFMO6amE2j3nCjJEL">Element Timing</a></span><span>&nbsp;</span><span>(</span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/document/d/1blFeMVdqxB0V3BAJh60ptOBFY7cJSXnf7VyW3wspbZ8/edit%23heading%3Dh.eny79fwwx642&amp;sa=D&amp;source=editors&amp;ust=1613252918897000&amp;usg=AOvVaw0T-YjkzO2VYaT520wSN8BN">explainer</a></span><span>) </span><span class="c0">(npm)</span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/document/d/1723wu4GZa8x8zSK0vb4NYg9xGtyVISEtGSGHcyL1tko/edit&amp;sa=D&amp;source=editors&amp;ust=1613252918897000&amp;usg=AOvVaw0erE0C4WbwKBdHQ6AAYZL3">Layout Stability</a></span><span>&nbsp;</span><span>- </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1FSpgaQobGOHKCHYdGSn2xK2vpiG-Ynw6Yvjhv4abtIU/edit?ts%3D5bc609d1%23slide%3Did.g445f3ec104_0_69&amp;sa=D&amp;source=editors&amp;ust=1613252918897000&amp;usg=AOvVaw1IP0ufslxOv5zt4YG08szX">slides</a></span><span>&nbsp;</span><span class="c0">(tdresser)</span></p><p class="c1"><span>Platform supported A/B</span><span>&nbsp;testing</span><span>&nbsp;</span><span>- </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1TIiTg1FudyFlIhi7YHmR_GpHyroyqHHRm-qXSY3IBLA/edit?ts%3D5bc85659%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918898000&amp;usg=AOvVaw32XGVe8Cgh0zwSyDppctdM">slides</a></span><span>&nbsp;</span><span class="c0">(tdresser)</span></p></td><td class="c30" colspan="1" rowspan="1"><p class="c1 c3"><span class="c0"></span></p></td></tr></tbody></table><h2 class="c6" id="h.k1h9wp2ek2f3"><span>Breakout sessions</span></h2><ul class="c12 lst-kix_l826szjijzgg-0 start"><li class="c1 c4 li-bullet-0"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/70&amp;sa=D&amp;source=editors&amp;ust=1613252918899000&amp;usg=AOvVaw0t0yygrdrUEPo0wktdGn1G">RT issue 70 - discuss with SW and webappsec folks</a></span></li></ul><p class="c1 c3"><span class="c0"></span></p><h1 class="c33" id="h.4eojuwvqc6m1"><span class="c28">Thursday minutes</span></h1><h2 class="c6" id="h.l4mnk7ap7bhp"><span class="c19">Goals and how to get there</span></h2><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: let’s talk about what this group does, why, and how. Our mission is to enable developers to monitor and improve the performance in ways that improve the user experience. We have two categories of features: the monitoring features (measure user experience), and performance enhancing features (improve user experience by making it faster).</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: We want to ship features in both specs and implementations. In specs, this means graduating the spec to CR. That can only happen if there are two browser implementors, which requires the features to be stable.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: There are two specs ready to move from PR to REC: requestIdleCallback and PageVisibility. Four are ready to move from CR to PR: HR Time, User Timing, Beacon, and PerformanceTimeline. And ServerTiming is ready to go from WD to CR. However, PageVisibility and Preload have some issues that make them harder to move along. ResourceTiming and ResourceHints have a lot of historical debt that needs to be addressed. LongTasks, PaintTiming, DeviceMemory, Reporting, NetworkErrorLogging are only implemented in one browser, and we’d like to see broader adoption of them.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: Maybe we need to understand why other browser vendors choose not to implement these and arrive at a consensus.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: We do a F2F usually sometime in the summer. We also have bi-weekly calls that are split between issue triage and new proposals. So far we’ve made great progress. But we also have technical debt, missing spec infrastructure integration (mostly integration with the Fetch spec to properly define what features are doing and what they’re not and avoid tricky bugs). I plan to work on this in the near future. Not all features are shipped in all browsers, so like Todd said it would be great to see if there are any blockers or reasons for lack of interest.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: It would be great to have more spec editors and more people writing WPTs. This would allow us for example to build more features on top of ResourceTiming and PerformanceTimeline. If anyone here wants to volunteer to do some of this work that would be greatly appreciated.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: For requestIdleCallback, there is 1 PR open in the HTML spec in order to integrate it in the event loop. That PR hasn’t landed yet: there was some feedback and it hasn’t landed yet. Looking at tests: it is almost green on two implementations and entirely red on other two (not implemented yet).</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: Should we review the details in each of the slots throughout the day?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: Are there slots for all of them?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: No, not all of them.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: Ok, let’s spend time on those that do not have slots allocated later.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: For HRTime, Todd opened an issue 11 minutes ago. Spectre is an issue for HRTime, so currently the spec allows browsers to clamp. But Phillipe wants us to re-run the spec through a security review to ensure it is safe. That means we cannot move it forward at this point.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: Should we assign that to someone?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: I’ll assign it to myself. I’ll get it scheduled for a security review.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: So, for HRTime, 0 open issues is a lie. In terms of tests, </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Charles</b>: They made a change in the IDL harness script that is only supported in Chrome 71. So there is a flag that you can add, maybe label:experimental. Does that help?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: It showed more green.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: But there’s still some failure on the IDL harness side.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: I’ll file a Chrome bug</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Markus</b>: I’ll file a Firefox bug</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: UserTiming: 0 bugs. Are there any objections to move UserTiming to L2?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: Can you remind us what is different in UT L2 versus L1? We added performance.mark and measure in workers and added clarifications to the mark names. When you reference a string in NavTiming, we’ve clarified the errors that should be thrown.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: And for L3, the key change is to be able to create arbitrary blobs of data that you would want.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: So for L2, it’s just adding the workers. So based on this, is there any push back?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: Same question for Beacon. 0 open issues. Regarding tests...</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: Almost green in 4 implementations. The tests are a bit flaky. The problem is that they rely on the server and client timing. We also need to look into the header tests, which were added during the security review. Is there push back assuming we follow up on the tests?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Xiaoqian</b>: Do we know if there are any changes from CR?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span><b>Todd</b>: </span><span>No, mostly on the fetch spec itself</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: Keepalive?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: No, the specific test for CORS behavior.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: I’ve filed Chrome bugs.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Alex</b>: I’ve made a reminder to follow up on tests.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Markus</b>: I can file a bug for Firefox, no context on this.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: Skip ServerTiming for later.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Xiaoqian</b>: Do we want privacy/security review for ServerTiming?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: Is that a requirement to ship to CR? Then yes.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: Most specs are using Respec, some of the newer ones are using bikeshed. Everyone familiar with those?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Markus</b>: no, but no explanation needed.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: Respec folks have been helpful when there are issues. Some issues are related to broken links. I talked to the Respec folks and this should be fixed shortly. That is, links and anchors will be verified. We should also host our stable versions, instead of linking to the latest, which potentially could break</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: do others do this?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: yes. There are some advantages to Bikeshed: verifies links, not sure if it verifies the anchors though? So there can still be issues. And Respec, there is some problems with flash. My opinion is that if we fix broken links then we can stick around with Respec.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: not worth converting things, but what should we use for new specifications? Do you propose we stick to Respec?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: We could stick to Respec for the next few months and see if link issues are fixed?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: We should have someone assigned to this.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: Do we have a tracker for this?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: Not for this meta issue. Can you follow up on this, Yoav?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: I can follow up on that. Can you open an issue and assign it to me?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span><b>Todd</b>: Sure.</span></p><h2 class="c6" id="h.pkbnoc88hs8z"><span class="c19">Preload</span></h2><p class="c1"><span class="c0"><b>Yoav</b>: 2 parts, today and tomorrow</span></p><p class="c1"><span class="c0">Current blocking issues and feature requests</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/preload/issues/127&amp;sa=D&amp;source=editors&amp;ust=1613252918905000&amp;usg=AOvVaw0W4rNwCzxAhTU-eMG6rYqg">Issue 127</a></span></p><p class="c1"><span class="c0"><b>Yoav</b>: Reason for the problem: mismatch of resource and fetch in the implementation</span></p><p class="c1"><span>… one &nbsp;solution is to add the </span><span class="c22">integrity</span><span class="c0">&nbsp;attribute, by the developers</span></p><p class="c1"><span class="c0"><b>Tim</b>: both the link and header?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: right</span></p><p class="c1"><span class="c0">… simpler solution for the implementers, extra burden for the developers</span></p><p class="c1"><span class="c0">… another proposal is to include the hash</span></p><p class="c1"><span class="c0">… simpler to do the matching</span></p><p class="c1"><span>… 3rd option is the link preload will not include any </span><span class="c22">integrity</span></p><p class="c1"><span><b>Tim</b>: including the </span><span class="c22">integrity</span><span class="c0">&nbsp;only in preload?</span></p><p class="c1"><span class="c0"><b>Todd</b>: only include it in the preload will be problematic if the preload fails</span></p><p class="c1"><span class="c0"><b>Alex</b>: will be problematic if the data is in a hash form</span></p><p class="c1"><span class="c0"><b>Todd</b>: it will require to storage all the hashes</span></p><p class="c1"><span class="c0"><b>Kouhei</b>: Option 1 will allow to save memory, as for Chrome</span></p><p class="c1"><span class="c0"><b>Alex</b>: if it will allow cache improvement, makes sense to me</span></p><p class="c1"><span class="c0"><b>Todd</b>: putting it in preload will prevent it getting into cache</span></p><p class="c1"><span class="c0"><b>Alex</b>: no reason to specify the hash type</span></p><p class="c1"><span class="c0"><b>Todd</b>: wait until someone use it</span></p><p class="c1"><span class="c0"><b>Alex</b>: wait until the download?</span></p><p class="c1"><span class="c0"><b>Stefan</b>: maybe just specify the hash in the algorithm</span></p><p class="c1"><span class="c0"><b>Tim</b>: if we know the hash for the whole time, it’s heavy</span></p><p class="c1"><span class="c0"><b>Todd</b>: it can choose to use a certain kind of hash</span></p><p class="c1"><span class="c0">.. allowing the link for preload in the hash seems a good thing</span></p><p class="c1"><span class="c0"><b>Yoav</b>: talked to webappsec, folks found value in the 1st proposal</span></p><p class="c1"><span class="c0">… we can further improve it in the future</span></p><p class="c1"><span class="c0"><b>Gilles</b>: there is a use case for this, both is useful, parallel to the issue</span></p><p class="c1"><span class="c0"><b>Yoav</b>: have you quantified the memory saved in that way?</span></p><p class="c1"><span class="c0"><b>Kouhei</b>: no exact number, we looked at a few cases, this is just one use case</span></p><p class="c1"><span class="c0">… if they use SRI, it’s possible to save MBs</span></p><p class="c1"><span class="c0"><b>Yoav</b>: will it be possible get rid of the buffers?</span></p><p class="c1"><span class="c0"><b>Kouhei</b>: not likely</span></p><p class="c1"><span class="c0">Yoav &amp;<b> Tim</b>: you can have multiple script tags, not sure if it will break</span></p><p class="c1"><span class="c0"><b>Alex</b>: this is easy to fix</span></p><p class="c1"><span class="c0"><b>Kouhei</b>: do we need the hash all the time?</span></p><p class="c1"><span class="c0"><b>Alex</b>: by the time preload is generated, no</span></p><p class="c1"><span class="c0"><b>Todd</b>: when hash comes down</span></p><p class="c1"><span class="c0"><b>Gilles</b>: if content changes in the script</span></p><p class="c1"><span class="c0"><b>Todd</b>: is hash itself in the body or header?</span></p><p class="c1"><span class="c0"><b>Gilles</b>: body, in the html</span></p><p class="c1"><span class="c0"><b>Todd</b>: when do the server actually provide the hash?</span></p><p class="c1"><span class="c0"><b>Gilles</b>: with H2-priority, both parties can compute that</span></p><p class="c1"><span class="c0"><b>Todd</b>: UA will have to provide piece of memory to contain the cache</span></p><p class="c1"><span class="c0"><b>Gilles</b>: it’s a tradeoff</span></p><p class="c1"><span class="c0"><b>Yoav</b>: if you don’t specify anything, it will assume all the documents are using it</span></p><p class="c1"><span class="c0">… if we include the hash, and make sure all browsers support it</span></p><p class="c1"><span class="c0">… step 2 is to improve how we compute the hash</span></p><p class="c1"><span class="c0"><b>Todd</b>: no differences to what preload already allows today</span></p><p class="c1"><span class="c5"><b>Resolution</b>: </span><span class="c22 c5">specify the full integrity to link rel preload in the immediate. Specify a mechanism to describe just the hash as a secondary priority.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/preload/issues/130&amp;sa=D&amp;source=editors&amp;ust=1613252918908000&amp;usg=AOvVaw24fa_XFZEj_tgwDXwjI6ve">Issue 130</a></span></p><p class="c1"><span class="c0"><b>Yoav</b>: it’s time to discuss whether the browsers should put limit to prefetch and preload chains</span></p><p class="c1"><span class="c0"><b>Tim</b>: how is it different from other content?</span></p><p class="c1"><span class="c0"><b>Alex</b>: can the UA say I’m not going to preload it?</span></p><p class="c1"><span><b>Yoav</b>: related to </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/preload/issues/129&amp;sa=D&amp;source=editors&amp;ust=1613252918908000&amp;usg=AOvVaw2S0ULgr_w8jfYCK3J5gJwG">issue #129</a></span></p><p class="c1"><span class="c0">… preload can be triggered in the header</span></p><p class="c1"><span class="c0">… UA can decide to not to preload</span></p><p class="c1"><span class="c0">… regarding the chains, preload open it for the contents</span></p><p class="c1"><span class="c0"><b>Todd</b>: is it a behavior for the parser?</span></p><p class="c1"><span class="c0">… prefetch says downloading has no preferences</span></p><p class="c1"><span class="c0"><b>Yoav</b>: if it receives the header, it’s under the regular fetch processing model</span></p><p class="c1"><span class="c0">… once we accept that..</span></p><p class="c1"><span class="c0"><b>Todd</b>: there will be a problem if the following fetch is not allowed</span></p><p class="c1"><span class="c0">… fetch spec should be changed?</span></p><p class="c1"><span class="c0"><b>Tim</b>: the UA can decide preload or prefetch can be ignored? </span></p><p class="c1"><span class="c0"><b>Yoav</b>: we can discuss this tomorrow</span></p><p class="c1"><span class="c0"><b>Alex</b>: we should say all of them are suggested</span></p><p class="c1"><span class="c0">… just a suggested performance improvement</span></p><p class="c1"><span class="c0">… we should change that</span></p><p class="c1"><span class="c0"><b>Yoav</b>: preload is not in the header, but in the markup</span></p><p class="c1"><span class="c0"><b>Alex</b>: net error happens, UA decides to block things</span></p><p class="c1"><span class="c0"><b>Yoav</b>: some of the use cases will break. Various loading patterns rely on preload fetches to be as reliable as e.g. script fetches. </span></p><p class="c1"><span class="c0"><b>Gilles</b>: may be a problem for those making websites</span></p><p class="c1"><span class="c0"><b>Yoav</b>: if UA has chosen not to load the content, not a problem</span></p><p class="c1"><span class="c0">… but if it decides to load the prefetch</span></p><p class="c1"><span class="c0"><b>Todd</b>: in general it’s fine, some UAs today will start the prefetch when you starting typing the URL, some in a different behavior</span></p><p class="c1"><span class="c0"><b>Tim</b>: shall we make it transparent to the page?</span></p><p class="c1"><span class="c0"><b>Todd</b>: meaning some type of flags?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: no document</span></p><p class="c1"><span class="c0"><b>Todd</b>: prerender flag behaves not perfectly</span></p><p class="c1"><span class="c0"><b>Yoav</b>: should be specified in the processing model</span></p><p class="c1"><span class="c0"><b>Todd</b>: is it a blocker for the preload spec itself?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: should be specified in the fetch spec, may affect the chains</span></p><p class="c1"><span class="c0"><b>Alex</b>: for a lot of fetchings no need to specify</span></p><p class="c1"><span class="c0">… in reality anything can be blocked, some of the reasons to block things have been specified</span></p><p class="c1"><span class="c0">… it should say all preloading is a suggestion</span></p><p class="c1"><span class="c0"><b>Todd</b>: Fetch spec says it can fail</span></p><p class="c1"><span class="c0"><b>Alex</b>: undetectable</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/preload/issues/97&amp;sa=D&amp;source=editors&amp;ust=1613252918910000&amp;usg=AOvVaw3K8-_mjUCi5nndz97xIMaR">Issue 97</a></span></p><p class="c1"><span class="c0"><b>Yoav</b>: We need to define a preload cache. Webkit and Chrome rely on their MemoryCache to implement it, but it’s underspecified, and I think Firefox ran into trouble there.</span></p><p class="c1"><span class="c0"><b>Markus</b>: may be true for Firefox</span></p><p class="c1"><span class="c0"><b>Yoav</b>: We need to define a minimal set of such cache in order for it to be interoperable</span></p><p class="c1"><span class="c0"><b>Todd</b>: we all have memory cache…</span></p><p class="c1"><span class="c0"><b>Yoav</b>: if there are multiple script tags, Chrome and Webkit will reuse the same resource. Other browsers may behave differently. We need to specify what the behavior should be and align.</span></p><p class="c1"><span class="c0"><b>Todd</b>: important for images</span></p><p class="c1"><span class="c0"><b>Yoav</b>: For images this is already defined in the html spec</span></p><p class="c1"><span class="c0"><b>Todd</b>: memory cache will force double download</span></p><p class="c1"><span class="c0"><b>Tim</b>: why not keep the same way for resource…</span></p><p class="c1"><span class="c0"><b>Todd</b>: in general, we should, but may have edge cases for privacy reasons</span></p><p class="c1"><span class="c0"><b>Alex</b>: like the idea not to double downloading</span></p><p class="c1"><span class="c0">… defining things knowing you are not using heavy memory</span></p><p class="c1"><span class="c0"><b>Yoav</b>: for memory pressures, dropping it from memory cache, and download it again…</span></p><p class="c1"><span class="c0"><b>Alex</b>: we may make suggestions randomly for privacy reason</span></p><p class="c1"><span class="c0"><b>Yoav</b>: UA can be allowed to make decisions</span></p><h2 class="c6" id="h.1r3yosflgth6"><span class="c19">Resource Hints</span></h2><p class="c1"><span class="c0"><b>Yoav</b>: 18 open issues, many related to prefetch and dns prefetch</span></p><p class="c1"><span class="c0">… Ilya suggested to break it into two parts, keep prefetch in the processing model of resource hints</span></p><p class="c1"><span class="c0">… the implementations for the 4 attributes seems unrelated to each other</span></p><p class="c1"><span class="c0"><b>Tim</b>: we should not make the inter-dependency problem worse, as the Firefox folks complained before</span></p><p class="c1"><span class="c0"><b>Yoav</b>: not sure for the Chrome side</span></p><p class="c1"><span class="c13 c5"><b>Resolution</b>: split the 4 attributes up and achieve the resource hints</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span>Issue </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/resource-hints/issues/78&amp;sa=D&amp;source=editors&amp;ust=1613252918912000&amp;usg=AOvVaw3XZvU5YkZXyW3iN7VTMmVR">78</a></span><span>&nbsp;&amp; </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/resource-hints/issues/82&amp;sa=D&amp;source=editors&amp;ust=1613252918912000&amp;usg=AOvVaw2XdHtRMkdtNsorsc6hhjGK">82</a></span></p><p class="c1"><span class="c0"><b>Yoav</b>: double-key caching and prefetch don’t really get along in browsers now</span></p><p class="c1"><span class="c0">… the double-key caching model is not compatible with current processing model</span></p><p class="c1"><span class="c0">… when it comes to service workers</span></p><p class="c1"><span class="c0">… you don't know which service worker will handle the sub resources</span></p><p class="c1"><span class="c0"><b>Tim</b>: any example?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: you don’t know the origin that will load the sub resources</span></p><p class="c1"><span class="c0">… you don’t know whether it will be used by a.com or b.com</span></p><p class="c1"><span class="c0">… even if we limit it to same origin, still no way to know which page will use it, and different pages can be handled by different scopes</span></p><p class="c1"><span class="c0"><b>Todd</b>: we don’t need to skip service workers</span></p><p class="c1"><span class="c0"><b>Yoav</b>: you have to prefetch html</span></p><p class="c1"><span class="c0">… I don’t know what the html will be</span></p><p class="c1"><span class="c0">… we need to figure out a way to define the scope</span></p><p class="c1"><span class="c0"><b>Todd</b>: this is important as it will affect the network implementation</span></p><p class="c1"><span class="c0"><b>Yoav</b>: not necessarily</span></p><p class="c1"><span class="c0">… it will work if you want to skip service workers</span></p><p class="c1"><span class="c0">… the developers shouldn’t know</span></p><p class="c1"><span class="c0">… for double-key we will need to skip it for privacy reason, but developers should be awared of</span></p><p class="c1"><span class="c0">… please bring use cases tomorrow</span></p><p class="c1"><span class="c0">… 9:00 - 9:45</span></p><p class="c1"><span class="c0"><b>Alex</b>: prefetching of subresources can be a topic for tomorrow</span></p><h2 class="c6" id="h.ez8q3dhgycc"><span class="c19">Performance timeline</span></h2><p class="c1"><span class="c0"><b>Yoav</b>: It’s the spec that underlines all the specs that we’re will talk about. Underlines the layering of the spec. This is something that we’re planning on keeping. We had complaints about the layering. We’re planning on keeping it as the infrastructure for everything else.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">… There’s a few issues that are marked as L2 blockers. Generally the L3 parts were scheduled tomorrow but we switched this around for the SW talk tomorrow.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span>… </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/100&amp;sa=D&amp;source=editors&amp;ust=1613252918913000&amp;usg=AOvVaw3_ufD3QO7KdCRlDip50P6_">issue 100</a></span><span class="c0"><b></b>: Ensure tests are clean and L2 is republished after updated.</span></p><p class="c1"><span class="c0"><b>Tod</b>: I don’t remember the specifics. This is really about are the tests clean.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: We could look at this that way. Tim can we file bugs and make that cleaner.</span></p><p class="c1"><span class="c0">… We could rename this to ensure tests are clean. Should we close this? Do we need to spell it out?</span></p><p class="c1"><span class="c0"><b>Tod</b>: Doesn’t matter, we historical track issues that are blocking the spec. That’s the reason I created. If you’d like to resolve the issue and track it another way.</span></p><p class="c1"><span class="c0"><b>Room</b>: all browsers or two green implementation</span></p><p class="c1"><span class="c0"><b>Yoav</b>: two green implementation. Ideally the same implementation being all green.</span></p><p class="c1"><span class="c0"><b>Tod</b>: But it could be different implementations if we have consensus.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/77&amp;sa=D&amp;source=editors&amp;ust=1613252918914000&amp;usg=AOvVaw02NF_c78pR3iTFPfi95-DU">Issue 77</a></span></p><p class="c1"><span class="c0"><b>Nicolás</b>: We need to include a small hook which allows other spec to add such a string to this static list. For example when we have (?) link timing. So that implementers know they have to update this static list. All that’s left is for me to add this.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: To be clear the goal is that new things will have to register rather than having to update performance timing everytime something is added.</span></p><p class="c1"><span class="c0"><b>Tim</b>: Are we willing to go back through and ask each spec to register.</span></p><p class="c1"><span class="c0"><b>Todd</b>: The work to complete this if I understand correctly is an active pull request. Do we have someone from Mozilla to review these PR. This is about adding types to the performance observer.</span></p><p class="c1"><span class="c0"><b>Mstange</b>: That person would be baku (sp?)</span></p><p class="c1"><span class="c0"><b>Alex</b>: I have no objections.</span></p><p class="c1"><span class="c0"><b>Todd</b>: So it would be a spec update, tests and implementation in two browsers.</span></p><p class="c1 c3"><span class="c0"></span></p><a id="id.ssyawtxronlw"></a><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/103&amp;sa=D&amp;source=editors&amp;ust=1613252918915000&amp;usg=AOvVaw2sO0GEEyj7d6TpRP4E5GFO">Issue 103</a></span><span class="c0"><b></b>: EntryType-specific parameters </span></p><p class="c1"><span class="c0"><b>Nicolás</b>: I can summarize. We have two possible entries in the dictionary. (1) … (2) we have the buffer flag that can dispatch to the performance timeline… There’s two case, 1) observe multiple entry type with the default param 2) Observe a single entry type with the parameters, this one is stackable and can be called multiple times and have it observe multiple entry with different kind of param. With the same observer. The caveat is that it overrides, I think this will be maintained. It will not stack.</span></p><p class="c1"><span class="c0">Will it nuke the ones that you’ve added it before?</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: No one has implemented this yet.</span></p><p class="c1"><span class="c0">…</span></p><p class="c1"><span class="c0"><b>Tim</b>: In terms of whether you nuke previous or not. I think you want to otherwise it’s confusing. Multiple entry type, single entry type. It would be weird to only nuke some and not all.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: People shouldn’t be using both.</span></p><p class="c1"><span class="c0"><b>Todd</b>: The use case is 8 3rd party scripts. You don’t want them to trash each other.</span></p><p class="c1"><span class="c0">…</span></p><p class="c1"><span class="c0"><b>Yoav</b>: It makes me want to ban mixing both.</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: We could throw an error since the stacking order is …</span></p><p class="c1"><span class="c0">… </span></p><p class="c1"><span class="c0">You can co-observe it will always add and never nuke anything.</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: I think we can break that, since people won’t rely on it. We could make them all stacking.</span></p><p class="c1"><span class="c0"><b>Todd</b>: How does it behave today?</span></p><p class="c1"><span class="c0">… The call are completely overwritten.</span></p><p class="c1"><span class="c0"><b>Tim</b>: I propose that we measure how often observe is called with different entry types. Get actual data.</span></p><p class="c1"><span class="c0">….</span></p><p class="c1"><span class="c0"><b>Todd</b>: There’s two options. The question is can we have the protocol allow adding multiple entry type and be consistent.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: This was the previous proposal but it got push back because it’s not consistent.</span></p><p class="c1"><span class="c0"><b>Alex</b>: This API should be consistent to other API part of the web platform. If you can observe twice it will observe both. In this case existing behavior should be preserved. If there’s multiple entry that are not in the spec, do the old behavior. If there’s one entry type with the type key assume that you're using the correct specified behavior and behave accordingly.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: I understand that it’s counter to other API in the web platform. But it doesn’t seem like something we can deprecrate in the short term.</span></p><p class="c1"><span class="c0"><b>Todd</b>: I think this is what they were asking. If the usage is low maybe we can break it now.</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: We’re talking about changing multiple calls, not just one.</span></p><p class="c1"><span class="c0"><b>Tim</b>: our hypothesis is that is rare to … its the only case that would break if we change the behavior. We can see how common this rare case is.</span></p><p class="c1"><span class="c0"><b>Alex</b>: … if we wanted to deprecate existing behavior we could if it has an array of entry type we could… if it has a dictionary …</span></p><p class="c1"><span class="c0"><b>Yoav</b>: if we’re mixing two behavior its complex. Throwing seems like the most dev friendly thing to do.</span></p><p class="c1"><span class="c0"><b>Room</b>: maybe…</span></p><p class="c1"><span class="c0"><b>Todd</b>: The tricky thing with throwing is some UA wont throw yet.</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Currently no one has implemented so there should be no risk of no one throwing.</span></p><p class="c1"><span class="c0">… We could add a new type. The reason we add new type.. There’s different types of entry.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Tim you look concerned.</span></p><p class="c1"><span class="c0"><b>Tim</b>: No it seems reasonable there’s question if we should deprecate existing behavior, if we don;’t want to … and then they should be able to play nicely together.</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: if we throw wew can keep the old behavior there won't be finicky causes.</span></p><p class="c1"><span class="c0"><b>Tim</b>: By can prevent mixing them by not throwing.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: EVen if we intent to keep the behavior, not allowing to mix them is hard to explain vs. either this or that.</span></p><p class="c1"><span class="c0"><b>Tim</b>: If they never overwrite and only add it's better from an ergo perspective. You have multiple problem with multiple long tasks.</span></p><p class="c1"><span class="c0"><b>Tim</b>: It should overwrite if it already exist.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: THat seems reasonably simple to exist and will enable either path, deprecation or not. Do we have stats on usage?</span></p><p class="c1"><span class="c0"><b>Tim</b>: we have instrumentation for over, not specifics.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: We can track over time how many people are moving to the single type behavior and see if it’s possible to deprecate in the future.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Is the reason, i going to ask the counter. Should observable support multiple entry…. What about the converse, should …</span></p><p class="c1"><span class="c0"><b>Tim</b>: I think there’s a difference that other calls have more metadata. The more the more difficult it is. One datapoint is that on chrome 13% of page visit have some use of performance observer.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Do they do anything of the interesting…</span></p><p class="c1"><span class="c0"><b>Yoav</b>: We will need to move all those if we try to deprecate the list.</span></p><p class="c1"><span class="c0"><b>Todd</b>: I bet all 12.9% of them are ???.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: I think we have understanding of what we want between throwing or not clob.</span></p><p class="c1"><span class="c0"><b>Tim</b>: I would verify that we can not clobber and ship that. But if people think throwing is better.</span></p><p class="c1"><span class="c0"><b>Charles</b>: I agree.</span></p><p class="c1"><span class="c0">…</span></p><p class="c1"><span class="c0"><b>Tim</b>: That could break existing content, we have to do research.</span></p><p class="c1"><span class="c0"><b>Todd</b>: One could cause break leading to extra data. The fix is … take records of the disconnect.</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: I think it’s likely that two observe call will be unlikely.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: If we’re opting for that we can don’t need more data, if we opt of throwing we need data.</span></p><p class="c1"><span class="c0"><b>Alex</b>: I think throwing would be great but I don’t feel strongly. It would be great for the future depreciation of the API. I think that would be a good thing to encourage.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Slight pref towards throwing. The users in the room does it matter.</span></p><p class="c1"><span class="c0"><b>Charles</b>: I think the observe … multiple calls, you sort on the entry type and compare. If the use count is very low we could compare an examine what it means.</span></p><p class="c1"><span class="c0">…</span></p><p class="c1"><span class="c0">How do you normally deprecate?</span></p><p class="c1"><span class="c0"><b>Tim</b>: normally we do reach out but we don’t deprecate something with that much usage. If its just a few libraries maybe my intuition is wrong.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Step 1 is … i read the thread and im struggling to see what the conclusions are. Can you summarize exactly what we will do at the end of the issue?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: At the top can you summarize the issue and say the current status.</span></p><p class="c1"><span class="c0"><b>Todd</b>: .... I'm not trying to micromanage, just trying to understanding.</span></p><p class="c1"><span class="c0"><b>Tim</b>: Best data I know how to gather how many libraries use this is to use HTTP archive.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Performance.observe with minification you’re going to have to wait for real world.</span></p><p class="c1"><span class="c0"><b>Tim</b>: But we can’t get library because of privacy reasons.</span></p><p class="c1"><span class="c0">…</span></p><p class="c1"><span class="c0"><b>Yoav</b>: if we’re pending the discussion if were going to deprecate in the future, we need to know if its 5 users or a million. Updating the libraries won't magically update their snippets.</span></p><p class="c1"><span class="c0"><b>Todd</b>: I assert we shouldn’t base our decision base on deprecation issue. What were looking at is how do we get the behavior we need and how to we get there with breaking the web.</span></p><p class="c1"><span class="c0"><b>Tim</b>: I agree, if we want to deprecate at some point. The shape of the API gives us leverage to get people to use the new API.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Deprecation is something for the UA, it's not a blocker.</span></p><p class="c1"><span class="c0"><b>Tim</b>: Should we check if we can add multiple entry type instead of throwing.</span></p><p class="c1"><span class="c0"><b>Todd</b>: I don’t have a pref, that’s why i'm asking you guys. Web compat makes the call given 12% adoption.</span></p><p class="c1"><span class="c0"><b>Tim</b>: My impression is neither option will break the web.</span></p><p class="c1"><span class="c0"><b>Todd</b>: If we have the string we’re already different. We can chose to throw or chose to add.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: We can throw regardless, even if depcaration is not viable. Choosing to throw will steer people towards the right thing.</span></p><p class="c1"><span class="c0"><b>Tim</b>: Low man hours to get the data but high latency to get the data in the pipeline.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Let’s conclude that we will get the data and make the decision.</span></p><p class="c1"><span class="c0"><b>Tim</b>: My concern is were throwing we don’t need the data.</span></p><p class="c1"><span class="c0"><b>Todd</b>: We want to move people towards the new API, if no one is overwriting it's safe to add the throwing.</span></p><p class="c1"><span class="c0"><b>Tim</b>: Ohhh… you want throw in the case that you add twice.</span></p><p class="c1"><span class="c0"><b>Todd</b>: …. *giving example* Once you first call observe you stuck in that mode and if you ever…</span></p><p class="c1"><span class="c0"><b>Alex</b>: With that observer.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: I think we should use that.</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: If they start using the new calls its easy to migrate.</span></p><p class="c1"><span class="c0"><b>Tim</b>: Are there examples where a single observer is shared between multiple scripts.</span></p><p class="c1"><span class="c0"><b>Room</b>: Let’s throw!</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c13 c5">Tag review?</span></p><p class="c1"><span class="c0">…: I think we need to go to CR again. Do you want to tag review again.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Should we pull performance timeline back to draft(?) since we’re waiting for these changes to be done?</span></p><p class="c1"><span class="c0"><b>Tim</b>: I don't have a sense of the overhead but it sounds correct to me.</span></p><p class="c1"><span class="c0"><b>Consensus</b>: Tag review sounds appropriate, we want to wait for these issues to be done first.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Can file a TAG review but they won't review it until these changes are done.</span></p><p class="c1 c3"><span class="c0"></span></p><a id="id.6hxnqn9wygwg"></a><p class="c1"><span class="c5">Buffered flag for performance observer - </span><span class="c9 c5"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/81&amp;sa=D&amp;source=editors&amp;ust=1613252918920000&amp;usg=AOvVaw1U2HLd6S1rkl7bGtGxj-qJ">issue 81</a></span></p><p class="c1"><span class="c0"><b>Charles</b>: Motivation is to register … notify for entry that happen before you registered. I landed a spec change on the dot observe flags and while queueing the entries in the spe. The ergo was a bit weird. The perf timeline will have a hook like other spec such as long task can register themselves. Define that type they are and can register the initial size of the buffer. The buffering logic will live in the perf timeline spec, wont be specific to the downstream spec. THat’s the spec changes, clearing buffer and changing size of the buffer will only live in the resource timing spec. For legacy reason. That won't get upstream, will stay in the timing spec. The result that will change the web today, one of which is long task. Let's say we want to buffer a 1000 of them, that will never be clearable, we cap out at 1000, those will never be clearable. THe other new thing is that we were moving towards a model where new spec will be observable only, were changing the spec the new spec and future new spec, those will be observe in the &nbsp;…. You’ll be able to get task by type.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: We could chose not to expose them. We could not allow access.</span></p><p class="c1"><span class="c0"><b>Tim</b>: I would prefer not to expose those via getEntry.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: the part that I have PR that we will talk about that defines buffering logic. That buffering logic has two different options we discussed, its overly complex and requiring copying. Would be great if we can kill all that and barring that only have that complexity in resource timing. From now on buffer by default up to only a certain limiting. Performance observer will do the buffering.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Can someone declare a proposal? Let me explain my current state of thing, … other types of timing we should be able to get script….</span></p><p class="c1"><span class="c0"><b>Tim</b>: I thought that for all types we want to access entries. The question is whether you access them via the performance timing or the buffered flag.</span></p><p class="c1"><span class="c0"><b>Todd</b>: If we want to allow that we need the concept of buffering everywhere. How do you define the buffers and do you allow them to define early in HTML. MY question is where is all of this written down?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Its in this issues (performance-timeline 81).</span></p><p class="c1"><span class="c0"><b>Todd</b>: We need to sort of buffering to ship. THis is the core of performance boserver. You can have a bunch of UA shiping with someone thing buffered and not and not have it specific.</span></p><p class="c1"><span class="c0"><b>Charles</b>: Today no one implemented the buffered flag.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: We could ship L2 and remove the buffer flag, add it to L3 with that logic.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Now that I’m clear on that i understand. In a world where we ship it with no buffering, performance timlineline and buffering will have to exist. Is that a fair place to ship specs, is that going to fulfil the goals and dream.</span></p><p class="c1"><span class="c0"><b>Tim</b>: will let you do that you want, won’t be pretty.</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: It’s a lot of work to do the buffering.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: We’re changing the model. Current model works for most use cases other than long task. Since we can’t get long tasks from the past.</span></p><p class="c1"><span class="c0"><b>Todd</b>: With long task you maybe get … of them overtime. It’s an anti buffer argument for long task.</span></p><p class="c1"><span class="c0"><b>Tim</b>: We got overaggressive in shipping it before the buffered task was specified.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Core gap for analytics vendors, not able to get long tasks for startup.</span></p><p class="c1"><span class="c0"><b>Charles</b>: Specifically we don’t want time….</span></p><p class="c1"><span class="c0"><b>Yoav</b>: We should not block on pretty, we should block on working.</span></p><p class="c1"><span class="c0"><b>Tim</b>: my concern is if we ship, should we be able to get entries for long tasks? I’m with todd that it seems bad. Ideally we would use long task as an opportunity to guide people to use the buffered flag. If we don’t want to ship on the current state the only other option is to postpone shipping the spec.</span></p><p class="c1"><span class="c0"><b>Mstange</b>: I think that’s desirable. What makes adding buffering for all of those a lot of work.</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Because they behave differently.</span></p><p class="c1"><span class="c0"><b>Todd</b>: When we say it’s a lot of work, i don’t think its lot of work, it’s that these people have a big stack of work. Is that fair?</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: im not sure its not a lot of work, but its prioritization, it would take a while to get done.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Would be blocking a lot of other things where we want… we decided that are hand wave-y specified. That is in L3 and we want to ship the functional version, want to close holes and wait for refactoring. We have functioning API with some gaps. Analytics providers are collecting the data, it may not be pretty, but it is working. I don’t think we need to wait for perfect.</span></p><p class="c1"><span class="c0"><b>Todd</b>: How does it collect first paint and ???. It is expose because we didn’t get buffering done? My point is its explicitly the opposite of what we wanted to do with performance observer. Chrome has made a decision to ship sooner rather than implementing buffering. I’m just saying I don’t actually care. I understand what analytics provider want …. Why don’t we just do it (fix it)?</span></p><p class="c1"><span class="c0"><b>Tim</b>: I agree with you, doing it feels the right thing, just concern how it might push other timeline. I’m leaning that we should block on them, need someone to do the work. Should be good at finding the prioritization. Raise it as problem.</span></p><p class="c1"><span class="c0"><b>Todd</b>: If reasonable buffering shows up that it would be something implementation in safari or Firefox?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Firefox is green. If we were to block on redefining buffer, would Firefox follow in terms of implementation.</span></p><p class="c1"><span class="c0"><b>Mstange</b>: can’t commit but I don’t think there would be a problem. Yes it’s in our interest to follow there.</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: How much would change with the new model.</span></p><p class="c1"><span class="c0"><b>Todd</b>: As each timing is implemented in the browser when buffering is enabled. They would all have to buffer some count of entries when the page is loaded then stop when its reached.</span></p><p class="c1"><span class="c0">…</span></p><p class="c1"><span class="c0"><b>Todd</b>: long task is new has no existence until a perf observe subscript to it. It would need some concept of buffering.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: concern is overhead of measurement. Do we want to start buffering long task even if page aren’t interested. Topic of header registration.</span></p><p class="c1"><span class="c0"><b>Charles</b>: And its’ not clearable.</span></p><p class="c1"><span class="c0"><b>Todd</b>: I dont think its hard to define, but will take end-to-end work to define.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: I think we have the overall picture of where we want things to be. Disagreement is whether we make it right now or in the future. L2 blocking or not. I understand the argument of make it so, but they are many moving pieces that will…</span></p><p class="c1"><span class="c0"><b>Todd</b>: if its for long task sub its fair to say no. If its for others it should not be in L2. We will need to pull the buffer flag. We will need to remove the buffer flag in L2, put it in L3 with all those changes.</span></p><p class="c1"><span class="c0"><b>Charles</b>: There will be a gap for historical long task data.</span></p><p class="c1"><span class="c0"><b>Mstange</b>: Seems reasonable for me, implementing the buffer flag means that turning on long task for each page load.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: We will need another flag for expensive measurements.</span></p><p class="c1"><span class="c0"><b>Charles</b>: We will need a PR.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Open the L3 branch and throw it all in there.</span></p><p class="c1"><span class="c0"><b>Charles</b>: Im ok with moving it and having a copy somewhere.</span></p><p class="c1"><span class="c0"><b>Alex</b>: from my POV that they wont think its an L2 blocker, I think we would want to implement it with the ability to clear this buffer and turning it on and off in the buffer even if its a draft spec in L3.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: buffer is okay, but clearing is a footgun where one vendor is clearing it for others.</span></p><p class="c1"><span class="c0"><b>Alex</b>: leaks are also bad.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: don’t disagree, we may need to think of ways where clearing could, time blocking can work without enabling one vendors to steal entries from another.</span></p><p class="c1"><span class="c5">Consensus</span><span class="c0">:</span></p><p class="c1"><span class="c0"><b>Yoav</b>: L2 we want to remove the buffer flag form the observe calls, we reinstate for the L3 for that, otherwise this issue should not block the current behavior, which is functional but not great.</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Can we assigned someone?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Charles.</span></p><h2 class="c6" id="h.xo8hwhlg5p49"><span class="c19">Nav timing</span></h2><p class="c1"><span><b>Yoav</b>: One new issue filed 8 days ago we need to triage (</span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/87&amp;sa=D&amp;source=editors&amp;ust=1613252918924000&amp;usg=AOvVaw3258Kx0g3G0uzfPoqlA4s9">87</a></span><span class="c0">). When reloading the page there’s navigation type entry which seems different in different implementation.</span></p><p class="c1"><span class="c0"><b>Todd</b>: This one will be hard to add a WPT. It requires a dep on the URL bar.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: You can’t test that in an iframe, manual test are a thing.</span></p><p class="c1"><span class="c0"><b>Tim</b>: According to the spec it should only be a reload if its a JS reload.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: This is a chrome bug that will be fixed, its not testable, just not a blocker.</span></p><p class="c1"><span class="c0"><b>Tim</b>: I’ll link the bug in the issue and close it.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span><b>Yoav</b>: Various L2 issues, again we have nav type (issue </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/85&amp;sa=D&amp;source=editors&amp;ust=1613252918925000&amp;usg=AOvVaw0A6EK_hHZBo1XsMVrOzolN">85</a></span><span class="c0">), should it be updated according to the current page. Should the iframe say reload vs navigate?</span></p><p class="c1"><span class="c0"><b>Todd</b>: Do we have good tests for these things? Lets add sub documents for each of them, should be fairly quick to ensure browsers are behaving properly.</span></p><p class="c1"><span class="c0"><b>Mstange</b>: All I can say is yes please.</span></p><p class="c1"><span class="c0"><b>Todd</b>: We don't need to go deep on this.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Need work and test.</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: what the expected behavior?</span></p><p class="c1"><span class="c0"><b>Todd</b>: Does a sub doc always inherit the parent document. The answer should be yes? Should it inherit for xorigin iframe?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: I don’t think we need to define that here. Definition in the spec point to the HTML and fetch, and then I don’t know what nested browsing contexts do, we should do whatever is defined there. We need to go through a chain of links to find that.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span><b>Yoav</b>: Issue </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/84&amp;sa=D&amp;source=editors&amp;ust=1613252918925000&amp;usg=AOvVaw2icD2weeCjd83v9dKTflZr">84</a></span><span class="c0"><b></b>: Need to make consistent have a single definition.</span></p><p class="c1"><span><b>Yoav</b>: Issue </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/83&amp;sa=D&amp;source=editors&amp;ust=1613252918926000&amp;usg=AOvVaw04eGcoyqsh9YL-foMpgbEP">83</a></span><span class="c0">:</span></p><p class="c1"><span class="c0"><b>Todd</b>: When you unload there’s unload time for the iframe, should unload includes the sub document unload time.</span></p><p class="c1"><span class="c0"><b>Tim</b>: Knowing xorigin iframe sounds like a leak?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Sound like something we should spec. We need to find the definition and adding tests.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Glance and each one occurs in order, we just don't have a hook.</span></p><p class="c1"><span><b>Yoav</b>: Issue </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/65&amp;sa=D&amp;source=editors&amp;ust=1613252918926000&amp;usg=AOvVaw1xBgdL8oW8TZ7yY6x0ZByx">65</a></span><span class="c0"><b></b>: Talked to marcos about this. There infra in place, will happen soon, boris will be happy.</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Did they break over time?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: I haven’t found why they were broken, respec changed the way links were done,these things can be fragile. TAlking to marcos he says there’s causes where we used the wrong format. Respec doesn’t make it easier unless you click on each.</span></p><p class="c1"><span class="c0"><b>Todd</b>: The reason we haven’t closed this since its 5 separate issues. We need to merge specs, should we use bikeshed. This is an uber issue.</span></p><p class="c1"><span class="c0"><b>Markus</b>: Close this one since all links are verified.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Verify, make respec a local tested.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Can anyone verify?</span></p><p class="c1"><span class="c0"><b>Markus</b>: I can do that.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">(scribe: cvazac)</span></p><h2 class="c6" id="h.8gnnjkz8e2u2"><span class="c19">Resource Timing</span></h2><p class="c1"><span><b>Yoav</b>: 2 issues, both around resource timing buffer. </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/resource-timing/pull/163&amp;sa=D&amp;source=editors&amp;ust=1613252918927000&amp;usg=AOvVaw1Wtzyznuutxdk_F_x_HXTE">https://github.com/w3c/resource-timing/pull/163</a></span><span class="c0">&nbsp;is about a secondary buffer and moving entries to the primary. But, if entries come in during that moment, or if developer doesn’t increase buffer size or clear, then entries get dropped on the floor.</span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/resource-timing/pull/168&amp;sa=D&amp;source=editors&amp;ust=1613252918927000&amp;usg=AOvVaw10e6lXtBynsg2lWHoZEyVc">168</a></span><span class="c0"><b></b>: accumulate entries in secondary buffer, when copying over to primary, fire the bufferful event synchronously in a loop, while there is room in the primary buffer. Will fire in a sync. Loop while developer is making room for them, else will drop entries. What’s currently implemented in webkit is a bit harder to explain in terms of spec processing model. With these two models, let’s weight complexity over dropping entries.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: the problem with (one) approach is that you can have too many entries before script gets a chance to execute.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: if buffer size is small, yes. Entries accumulate and overflow secondary buffer.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: if we have default 250, if you get 600 IMG elements, 100 entries will get dropped. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: yes if that happens in between the time we queue the task and execute the task.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: this is an issue whether dev changes buffer size or not. Problem is, we drop before script even has a chance to do anything. We want script to be able to react to the full event. Why not just set buffer size to be bigger?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: focus! :)</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: in the second approach, repeatedly fire event synchronously. Ah, they can be queued, but not…</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: primary buffer gets full at 200, more resource timing entries coming in in the background. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: if primary buffer has space, entries go to primary. Otherwise secondary.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: PRs 168 &amp; 163</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: &nbsp;all members of the WG need to be able to see the status of both proposals</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: [summarizes two proposals] </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: one proposal: secondary buffer is unlimited, fire event sync until secondary not empty. Only drop entries if buffer size isn’t changed / cleared. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Markus</b>: why not have zero sized primary buffer if secondary buffer is unlimited?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">[clarification here]</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Markus</b>: this is the same as having a 2x buffer, and firing event when it’s half full</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: problem is that we implemented it a certain way, need to find something that works now</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: webkit implemented their processing model, other browsers are firing event sync, guarantees that you can’t have more entries come in, until the event callback has fired. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: we don’t implement event, we just allow setting buffer size</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: we had to change the way we we do things for security reasons</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">[some security items mentioned here]</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Markus</b>: [to check with current Firefox impl]</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: having drafted these two, the outcome of this is just spec changes to the RT spec, no other spec. So I’m fine with either one. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: this same type of problem will come up with all buffered entry types, even user timing</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nic</b>: but this is the only one with a bufferfull event</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: with the L3 timeline updates we plan on doing, this is easier because we just drop when limit is reached, and you should have had a PO registered</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: edge doesn’t support this event? Weird. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: yeah, we just increased our buffer, but no stats. We think it’s not yet an issue.It’s probably 500 or 100.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Markus</b>: firefox bufferfull event is synchronous</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: is full buffer a bad thing?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: you can’t stop javascript from taking more memory, nothing preventing users from inserting 1000s of dom nodes</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: in 168, you could define unlimited as 5x or some big enough number to have a cap, but ensure that we really don’t drop entries. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: someone who doesn’t care about resource timing entries has no idea that they are using this memory</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: but if we fire the event and no one does anything, we drop the secondary buffer</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: if we increase buffer size by 1, will that…? [Receives clarification]</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nicol&aacute;s</b>: secondary buffer should always be empty at the end of the sync loop</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: this is a safe design, pages can’t mess this up. Outside of the problems PO solves. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: Problem is, firing the bufferfull event itself can add more entries (sync XHR, sync fetch image from catch)</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: don’t blame UAs for not conforming to specs that they weren’t consulted on</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: example: when you fire event, callback might insert background image, image might be cached, would add another entry</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: according to spec, that image req should be async</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: background downloads _could_ be completing, and put into the timeline. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: is queuing an entry sync/async?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: queuing an entry for the PO has to happen sync. At end of microtask, that’s when we invoke observers.</span></p><p class="c1"><span class="c0"><b>Todd</b>: resources _could_ inject themselves magically during that moment. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: sync XHR, everyone loves! :) We need to reexamine the secondary buffer, copy things from it, don’t assume it’s empty [impl. Details…]. Otherwise, we agree to go with the 168 design and add the tests and modify the impls. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: and we should use sync XHRs in the test!</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span><b>Next issue</b>: </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/82&amp;sa=D&amp;source=editors&amp;ust=1613252918932000&amp;usg=AOvVaw1u-ev2VtT80uoCawFjIH5Z">clarify when an entry is added to the buffer</a></span><span class="c0">.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: it’s not spec-ed if sync or async. Given discussion, don’t know what’s right call. Previously on call, we said sync. So we can know that the entry is there when onload for the resource fires. But some UAs inject off thread, so is this viable?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: i assert that these should be synchronous. Specs shouldn’t encourage suboptimal behavior. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Markus</b>: if you listen to load for a resource, you’d be able to get PO notification before the load event fired. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: if you call getEntries consecutively, new entries could be added in between</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: we need to integrate this into fetch. It’s not speced when load event finishes. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: yes, tie into fetch integration. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nic</b>: we’ve seen two things, 1) if last element of page, in the load handler, sometimes the RT entry isn’t there. 2) in edge, sometimes the responseEnd of the RT entry might be zero (incomplete). Weird oddities with this being inconsistent. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: What do you mean by RT entry not being there?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nic</b>: main page load event, it might not have the RT entry for the final resource that was loaded, causing the load event of the page to fire. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: the spec ambiguity leads to bugs? You’d prefer sync?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nic</b>: yes, during page onload, i’d like all entries to be there. If image delays onload, it should be in timeline during page onload handler. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: and this would be better for testing, more deterministic</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Gilles</b>: so you setTimeout? But do the timestamps still lineup?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nic</b>: yes they line up. Also, for xhrs, in onload handler for XHRs, the XHR might not be there. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: if this better or worse with PO v. timeline? We are trying to motivate people to PO, but it doesn’t help you. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Markus</b>: issues in firefox?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nic</b>: I will check.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Markus</b>: we submit entry and then fire event, so they should be there (in firefox)</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">[clarification here]</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: a) we should define this and b) we should dispatch sync and c) to define this, we need fetch integration, so that’s L3</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: cheap hand-wavy solution could be…</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: but not every subresource blocks onload</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: i’m talking about its OWN load event. IMG.onload, the entry needs to be there. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: because IMGs are weird between full download and onload event…</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: onload should not fire on image dimensions. That happens much earlier. But - let’s skip that discussion. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: so in general, we agree, when onload fires, entry should be there </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: resource could be finished before trailers are parsed. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: but that’s only server timing on firefox, right?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Alex</b>: supported - but not used (webkit)</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: respondEnd…</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: right, is that the body or the trailers. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: yes, it’s weird to wait on the trailed to fire onload. Or in terms of calc. responseEnd time. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: that is a separate issue, we want to say: “those entries are added when the resource download is complete”, then define “download complete” when we have fetch integration. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: hand wavy in L2 is not what we want, maybe an informal note, otherwise wait for L3</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: we want massive rewrite to be in L3, so nothing in L2 about this?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: informal note is fine. Also, not all elements have load events. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: I want to talk about dispatching entries sync, not load events. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: useless to add dispatch entries sync, if we don’t define download complete. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span><b>Takeaway</b>: Ryosuke to </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/82%23issuecomment-433037223&amp;sa=D&amp;source=editors&amp;ust=1613252918936000&amp;usg=AOvVaw3r9f6lDb8Wcvl2HSJi4VIj">summarize Issue 82</a></span><span class="c0">&nbsp;in the note. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5"><b>Third issue</b>: </span><span class="c9 c5"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/139&amp;sa=D&amp;source=editors&amp;ust=1613252918936000&amp;usg=AOvVaw0DHolSBsPE-51rFFWNA75Y">Navigation Preloads can have negative times</a></span></p><p class="c1 c3"><span class="c13 c5"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: should we save this for when service workers people here? A step or two might be out of order, from fetch spec, seeing some negative numbers, chrome impl, as big as -100ms.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: why is that bad?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: yeah. We have historically avoided negative numbers. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nicolás</b>: maybe just add a note to the spec, sometimes timestamps can be negative. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: does the group have any objections about this. Nic?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nic</b>: we do data validation, might be throwing out anything with negative numbers. I will check.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: you throw away, does it break stuff?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nic</b>: depends. If WG allows negative, we will take that into account in boomerang. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: either we delay navigation preload by 100s of ms, or we redefine (some steps of fetch) - but not sure we can, adding note is reasonable, unless people thinks this breaks the world.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: but navigation preload is opt-in. So that makes it ok? (to shift the time earlier)</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Facebook fella</b>: you can have a preload, but once a service worker starts up, it can fetch something else that won’t line up…. (with time origin?). </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: only time origin shifts</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: do we decide what TO is, just pick lowest timestamp we see?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nicolás</b>: that will break….</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Markus</b>: making some numbers bigger makes things bad, and the negative number is actually correct. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: [mentions wanderviews’s comment in thread]. Negative is the better option. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nic</b>: one other issue, tracking the onbeforeunload event, and that would have been negative time, but we avoided. But if we’re ok with negative numbers, that might open some things up. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: if we see breakage, what would we see? Analytics packages throwing exceptions</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: collection code dying</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nic</b>: collection code but also backend validation, and that we wouldn’t have visibility until someone noticed that beacon counts were low, might never know</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: [approves]</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: everything else in RT is just legwork - motivated people are encouraged to help Yoav with it.</span></p><p class="c1 c3"><span class="c0"></span></p><h2 class="c6" id="h.yau6ljr72hdr"><span class="c19">Page Visibility</span></h2><p class="c1"><span class="c9 c5"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/34&amp;sa=D&amp;source=editors&amp;ust=1613252918939000&amp;usg=AOvVaw1ESUJmpUUCLaIFLmXtmBda">https://github.com/w3c/page-visibility/issues/34</a></span></p><p class="c1 c3"><span class="c13 c5"></span></p><p class="c1"><span class="c0"><b>Todd</b>: this is just waiting for me, I just need free time. But - not before 11/5. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nicolás</b>: 11/6th it is!</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: [will do the best he can]</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: Shubhie could maybe do this?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Xiaoqian</b>: but is this not testable?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: it is, just not in WPTs</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: you can use WebDriver</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: there’s an open bug for WPT to use WD, bug is still open</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: even if you use WD, it’s tied to specific platform. But, manual test is ok. We will survive. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: one step at time, let’s update the text, check current tests, what manual tests do we need, then can we automate the manual tests? Those are the steps. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: [details manual test]</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: spec will say MAY, we are not requiring every browser to ….</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: there exists platforms where a test is not really possible</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Xiaoqian</b>: is this not even normative text?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: there could be existing browsers that break the normative text already. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Xiaoqian</b>: if we are able to test the obscured window…</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: yes, we could test who has implemented this</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Alex</b>: a custom a11y tool perhaps?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: we all agree that this doesn’t affect spec status?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: if this is only adding a MAY…. this might be us just republishing a PR. might require a MAY, get thru MUSTs and MUST NOTs</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: that’s one thing, other issue is adding hooks into where hidden and visible actually happen so other specs can use those definitions, which is editorial, doesn’t require new tests. This exposes the definitions, even if they are badly defined. </span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/40&amp;sa=D&amp;source=editors&amp;ust=1613252918941000&amp;usg=AOvVaw0JVkovM6KXeNoo8D4VPWSf">https://github.com/w3c/page-visibility/issues/40</a></span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: defining the hook is trivial, whoever wants to use the hook should just do it. Is punting reasonable?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: this is completely editorial. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: anyone can take this from me. </span></p><p class="c1 c3"><span class="c0"></span></p><h2 class="c6" id="h.wch7tfcp89o6"><span class="c19">requestIdleCallback</span></h2><p class="c1"><span><b>Yoav</b>: </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/requestidlecallback/issues/70&amp;sa=D&amp;source=editors&amp;ust=1613252918942000&amp;usg=AOvVaw3PMQn-me6CCrAQRO7jRBv9">#70</a></span><span><b></b>: but what is “idle time”? That requires HTML PR </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/whatwg/html/pull/4104&amp;sa=D&amp;source=editors&amp;ust=1613252918942000&amp;usg=AOvVaw28Q3sC-tG8z_8PyvXPiYcL">#4104</a></span><span>&nbsp;to land, but I couldn’t find a committer to get this merged quite yet. So, we are good to close this when the HTML one is merged? Also, will the HTML change also close </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/requestidlecallback/issues/71&amp;sa=D&amp;source=editors&amp;ust=1613252918942000&amp;usg=AOvVaw2difFjrpTTtGBjb5-i0yfC">71</a></span><span class="c0">? </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: [looking]</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: doesn’t appear fixed to me. “Idle period deadline” isn’t defined. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: PR fixes when ambiguity around when algorithm runs. But, in step 5… With iframes, each document has different timers….</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: cross origin iframes aren’t on same event loop (chrome only)</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: window.open, can have timers in there (or same origin iframes)....</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: AFAICT, we need same refactoring in HTML spec, event loop needs to be aware of which tasks to invoke… The times are part of the global object, but there could be multiple global objects. We can’t say “we have no timers on my global object” and say that means we’re idle. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: In the same place we’re modifying in HTML spec, we need to specify time when next task will run. Does that make sense?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: I’m pretty far out from this. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: yep, this makes sense, but editor isn’t in the room. But this aligns with blink same-origin, so maybe this won’t be controversial?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Takeaway</b>: Ryosuke to comment in case. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: [type type type]</span></p><p class="c1 c3"><span class="c0"></span></p><h2 class="c6" id="h.yf8ugxoqr11h"><span class="c19">Long Tasks</span></h2><p class="c1"><span class="c0"><b>Nicolás</b>: to begin, what is the status of LT for other browsers?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: can we do anything from spec perspective to encourage other browsers to implement?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Markus</b>: we are in progress</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: we want “all tasks” to be complete, not just callback tasks</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nicol&aacute;s</b>: I already merged that to HTML spec, so we have micro tasks included in duration, and “update the rendering” step. And we include work outside of the event loop. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: that is what we’d like to see. We intend to implement after we get to PO</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: we don’t have (microtask?) implemented. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: I’m looking forward to hearing success stories for people who got benefit out of this.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nic</b>: we use for TTI, similar to definition of Lighthouse and WPT, but we’re RUM, so don’t have all the data. This is for busy-ness of main thread. Also - diagnostics. Customers can look at our waterfall, all RT data, page characteristics, long tasks overlayed. Customers see periods of time with no network activity, but LTs also help to explain that. Gives customers visibility into what’s going on in the page. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: but that’s just collecting information. But how are they using that to fix problems?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nic</b>: getting the data is the first step. Our LT instrumentation allowed a customer to see a 5 second LT, see what happens before/after, encourage them to break up script. Also checking in page interactions. Rage clicks. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: have worked with internal MSFT sites, they use rAF w duration, which kills battery. In browsers that have LT, the register a PO, and then they measure the impact of third-party ads, and when they are interfering, or when own scripts are causing LTs. They were using LTs to blame ads, but they can’t use it for that anymore. They would kick out ad (vendors) when detect LTs. Perhaps FB uses as well?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Benoit</b>: nope. Maybe for non JS issues. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: yes, your instrumentation is so good, LTs not necessary. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Benoit</b>: because not as useful without the attribution because we have so much code.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: Ryosuke wants to know the tangible benefit. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Gilles</b>: we want historical LTs, buffer all the things! We believe the bottlenecks happen before we register. Also, we let some users to write script. We want to measure that terrible javascript, but we can’t register in time. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: Ryosuke, you are waiting to hear that this is super useful before you implement. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Gilles</b>: we need our measurement to be not invasive, loads late</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nicol&aacute;s</b>: other issues are how to make LTs more useful, to find the culprit, attribution and call stack. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: punt because it’s the same issue as the self profiling spec for getting stacks</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: one proposal: identify something as part of rendering pipeline, javascript, other browser work. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nicolás</b>: event loop, render, non event loop - this should be trivial to add to LTs, would be good first step. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Alex</b>: for us, not clear break between render and “other” tasks</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: in Edge, we’ve been putting markers in our code in accordance with HTML spec, for consistency</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: task could be compute scrolloffset, most time would be in layout</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: in the HTML spec, we could put start/stop markers</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: example: on a page, there’s a mousemove event that forces sync layout, will never see time spent in rendering. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: time would be in mousemove event? It’d be ~50ms, you’d see LT for that. If you got callstack, you could diagnose the sync layout - in some sort of imaginary far off world.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: if we were to do attribution, we need more than the three categories</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: some devs are ready to build on this model. If you knew “rendering” it’d give you more info.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Benoit</b>: yes, that would help - but difficult in practice. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: both of these approaches help different devs. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: worried that going from coarse to specific, there isn’t really a migration path</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: this is sort of an expert feature, and yet, it could be misleading to get a certain type of LT, especially if the type is happening because of something else. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: maybe this is only useful for devs that are used to tracing with Chrome devtools. Useful for some people, but how far from are we from actual attribution. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: I agree that this is low priority</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: but my sites that use rAf instead of LTs… and my devs have found limitations in chrome impl. They want to know about ANY long tasks. Even if there are things not from our script. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nicol&aacute;s</b>: this isn’t about when we are firing events, we are talking about entry classification</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: if LT fired all types of things, they’d throw away the rAf impl. They would be happy with unnamed/untyped entries. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nicol&aacute;s</b>: we currently just call them script. There’s a bug, we don’t expose microtasks. We don’t consider the time of the microtasks. Should be included. Just a bug. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: GC 60ms will cause LT of “script”? (Yes.)</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: rename “script” to “unknown” (or “unclassified”).</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Todd</b>: still want to see all the long things. </span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: let’s break!</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: next steps: don’t call them “scripts”, low-priority: let’s track better attribution at some point, also classification. </span></p><p class="c1 c3"><span class="c0"></span></p><h2 class="c6" id="h.erbnmou9so7a"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/network-error-logging/issues/93&amp;sa=D&amp;source=editors&amp;ust=1613252918948000&amp;usg=AOvVaw2omEJgPFu2846L2yG4vUoJ">NEL</a></span><span>&nbsp;&amp; Distributed Tracing</span></h2><ul class="c12 lst-kix_7gx7dxrc3itt-0 start"><li class="c1 c4 li-bullet-0"><span>Douglas Creager:<br></span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/a/google.com/presentation/d/e/2PACX-1vQNgUnwPtR_eGXNtYCLHC42WobuPssUzTULKFS4rTc048wx08O5p0uVSjBNEoYqJMdfnuNWGOiHDoTi/pub?start%3Dfalse%26loop%3Dfalse%26delayms%3D3000&amp;sa=D&amp;source=editors&amp;ust=1613252918948000&amp;usg=AOvVaw2UmddHvT58MTHtGPyeJfIQ">Slides</a></span></li></ul><p class="c1 c42"><span class="c0">NEL overview:</span></p><ul class="c12 lst-kix_7gx7dxrc3itt-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">Looking at how we can collaborate better with distributed tracing</span></li><li class="c1 c2 li-bullet-0"><span class="c0">Without NEL:</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-2 start"><li class="c1 c10 li-bullet-0"><span class="c0">End user makes request to server</span></li><li class="c1 c10 li-bullet-0"><span class="c0">Server logs things about request</span></li><li class="c1 c10 li-bullet-0"><span class="c0">BUT! If the request doesn’t make it to the server, then we don’t know anything bad happened.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-1"><li class="c1 c2 li-bullet-0"><span class="c0">Instead, we can collect information about failing requests in the client, and then send this data up to some collector, which aggregates information about failures.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-2 start"><li class="c1 c10 li-bullet-0"><span class="c0">The collector needs to be super resilient.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-1"><li class="c1 c2 li-bullet-0"><span class="c0">Security &amp; Privacy:</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-2 start"><li class="c1 c10 li-bullet-0"><span class="c0">Only report information the server already has access to.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-3 start"><li class="c1 c41 li-bullet-0"><span class="c0">E.g., can’t expose which DNS server is being used for privacy reasons.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-2"><li class="c1 c10 li-bullet-0"><span class="c0">Server administrator controls whether reports are gathered for their domain.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-1"><li class="c1 c2 li-bullet-0"><span class="c0"><b>Integration with Distributed Tracing</b>: </span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-2 start"><li class="c1 c10 li-bullet-0"><span class="c0">Request from Comcast and others.</span></li><li class="c1 c10 li-bullet-0"><span class="c0">Have the NEL policy header contain a request to include arbitrary request &amp; response headers in the NEL reports.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-3 start"><li class="c1 c41 li-bullet-0"><span class="c0">This enables requesting that the trace parent header is included in NEL reports.</span></li><li class="c1 c41 li-bullet-0"><span class="c0">Could also ask for etags or cache-validation headers.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-2"><li class="c1 c10 li-bullet-0"><span class="c0">Syntax doesn’t seem too controversial.</span></li><li class="c1 c10 li-bullet-0"><span class="c0">We’re primarily worried about security &amp; privacy.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-3 start"><li class="c1 c41 li-bullet-0"><span class="c0">The server does already have the headers, so this should be fine.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-0"><li class="c1 c4 li-bullet-0"><span class="c0"><b>Morgan Maclean</b>: Do we mean client side tracing?</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Doug</b>: ?</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Ted Young:</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">If distributed tracing is initiated in the browser, and the request never gets to the server, this isn’t super useful.</span></li><li class="c1 c2 li-bullet-0"><span class="c0">If we want to collect distributed tracing but not have a security nightmare, could the server talk directly to the collector?</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-0"><li class="c1 c4 li-bullet-0"><span class="c0">Doug:</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">We’ve tried to split out reporting uploads and NEL.</span></li><li class="c1 c2 li-bullet-0"><span class="c0">CSP &amp; others are also working on using the reporting API for this.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-0"><li class="c1 c4 li-bullet-0"><span class="c0"><b>Ted</b>: This would be more necessary if more of this ran natively in browsers.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Doug</b>: This would factor out needing to think about delivery.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Yoav</b>: What kind of traces are we referring to?</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Ted</b>: Analytic information - the user does a sequence of activities, making requests etc.</span></li><li class="c1 c4 li-bullet-0"><span class="c34">Alois</span><span class="c0"><b></b>: When we talk about traces:</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">Grouping of interaction that started somewhere, with some sub-interactions, or “spans”.</span></li><li class="c1 c2 li-bullet-0"><span class="c0"><b>Traces that start in the browser</b>: span’s based on user timing, or XHRs.</span></li><li class="c1 c2 li-bullet-0"><span class="c0">A trace is a hierarchy of spans which may come from different nodes.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-0"><li class="c1 c4 li-bullet-0"><span class="c0"><b>Yoav</b>: In JS, using existing performance APIs, you’d construct spans yourself.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Ted</b>: Those APIs don’t have hierarchies. We’d ideally have nested blocks.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Yoav</b>: We want to use current mechanisms, potentially require L3. But we’ll need to write the logic to produce the trace in JS.</span></li><li class="c1 c4 li-bullet-0"><span class="c34">Alois</span><span class="c0"><b></b>: Trace-Context &amp; Trace-State. Trace-State lets you add extra information. </span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Ryosuke</b>: How does this relate to NEL?</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Douglas</b>: Yes, we’ve moved from discussing NEL to one use-case that this would allow.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Yoav</b>: The use case is adding the trace id to NEL reports?</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Douglas</b>: It’s open to figure out how distributed tracing will work in the browser. To avoid depending on how distributed tracing will work, enabling arbitrary headers will let us integrate no matter what.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Yoav</b>: Let’s try to wrap up the discussion on this issue, talk about server timing, and then get an overview on use-cases, primitives, etc.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Todd</b>: If the only use-case is for distributed timing, why would we do this first?</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Douglas</b>: Other use cases for this (NEL) mechanism:</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">Anycast IP addresses - IP doesn’t indicate which location served a request. This could be used to indicate where the request was served.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-0"><li class="c1 c4 li-bullet-0"><span class="c0"><b>Yoav</b>: So this would give you the last server that actually worked.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Ryosuke</b>: We’re talking request/response headers.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Douglas</b>: The browser chooses an ID which is sent via a request header.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Ryosuke</b>: This is an entirely new feature?</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Ted</b>: Distributed tracing as it currently stands doesn’t benefit, but as we improve distributed tracing, this will become important.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Yoav</b>: It sounds like we want to split out these concepts.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Ryosuke</b>: In the case where we report a response header, what do we include?</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Doug</b>: The browser will receive a response from the server closest to the user, and reflect any response headers into the NEL reports.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Ryosuke</b>: </span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">I load A.com, which fails to load B.png (on a separate origin).</span></li><li class="c1 c2 li-bullet-0"><span class="c0">What header is sent, to which collector?</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-0"><li class="c1 c4 li-bullet-0"><span class="c0"><b>Doug</b>: No report is sent to A.com.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Ryosuke</b>: I load A.com, which fails to load B.png (on the same origin).</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Doug</b>: We’d receive a success report for A.com, then a separate report for B.png. </span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">If the server asked for a specific header, then whatever etag header came in the index.html response would be reflected.</span></li><li class="c1 c2 li-bullet-0"><span class="c0">The failure report wouldn’t include any headers.</span></li><li class="c1 c2 li-bullet-0"><span class="c0">This is all isolated to individual network requests.</span></li></ul><ul class="c12 lst-kix_7gx7dxrc3itt-0"><li class="c1 c4 li-bullet-0"><span class="c0"><b>Tim</b>: Is this useful without distributed tracing?</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Ted</b>: Yes.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Doug</b>: Ilya commented that we should elaborate on other use-cases.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Nick</b>: From a distributed tracing standpoint. This is useful, if distributed tracing headers are sent with requests.</span></li></ul><h2 class="c6" id="h.4ugephvtq2j8"><span class="c19">Server Timing</span></h2><ul class="c12 lst-kix_2bexye2j2yhs-0 start"><li class="c1 c4 li-bullet-0"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/server-timing/issues/42&amp;sa=D&amp;source=editors&amp;ust=1613252918953000&amp;usg=AOvVaw1xPpZdL8xPOn6e1GVRNSzm">https://github.com/w3c/server-timing/issues/42</a></span></li><li class="c1 c4 li-bullet-0"><span class="c0">Charlie:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">Server timing items can be separated by a comma</span></li><li class="c1 c2 li-bullet-0"><span class="c0">We try to keep parsing when we can</span></li><li class="c1 c2 li-bullet-0"><span class="c0">On tests, Chrome &amp; Safari fail two degenerate cases where we don’t keep going.</span></li><li class="c1 c2 li-bullet-0"><span class="c0">Can we be more strict with the parsing strategy?</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c0"><b>Yoav</b>: </span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0"><b>General philosophy question</b>: should we parse slightly invalid input.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c0">Tim:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">Wouldn’t we break some stuff?</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c0">Yoav:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">Some server aggregation, yes.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c0">Todd:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">These folks are already somewhat broken.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c0"><b>Charlie</b>: </span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">If we were to do it over, we’d only allow sloppy whitespace.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c0">Alex:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">In general, we should be as strict as we possibly can.</span></li><li class="c1 c2 li-bullet-0"><span class="c0">If something doesn’t fit, completely discard it and fail horribly.</span></li><li class="c1 c2 li-bullet-0"><span class="c0">Otherwise we encourage development which takes advantage of a quirk, and we get pressure to become forgiving for the sake of compat.</span></li><li class="c1 c2 li-bullet-0"><span class="c0">This makes an unruly parser.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c0"><b>Yoav</b>: </span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">The processing model is well defined, it doesn’t encourage a slippery slope of becoming more forgiving overtime. It’s forgiving in well-defined ways.</span></li><li class="c1 c2 li-bullet-0"><span class="c0">I agree we should be strict.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c0">Yoav:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">Anyone disagree on being strict?</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c0">Charlie:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">The backstory here is that they were passing in Chrome and Webkit.</span></li><li class="c1 c2 li-bullet-0"><span class="c0">Mozilla made a change and upstreamed, breaking tests in Chrome &amp; Webkit.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c0">Todd:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">How many months has this been shipped?</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c0"><b>Charlie</b>: 7-8 months</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Todd</b>: The question is how much is this depended on?</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Alex</b>: How long has it been shipping in FF?</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Markus</b>: 3-4 months</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Charlie</b>: We could add a use counter.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Yoav</b>: Yeah, we should do that. How used is server timing today?</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Todd</b>: </span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">We can drive the decision from the data. If the data says we can make this stricter, we should do it, otherwise, we shouldn’t.</span></li><li class="c1 c2 li-bullet-0"><span class="c0">Anyone disagree?</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c0"><b>Charlie</b>: Less than 1.8% of sites use this.</span></li><li class="c1 c4 li-bullet-0"><span class="c0"><b>Yoav</b>: Any other issues?</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">Server timing in the context of distributed tracing.</span></li><li class="c1 c2 li-bullet-0"><span class="c0">Distributed tracing reached out to us because server timing seems potentially relevant.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c39">Alois</span><span class="c0">:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">Brief Primer</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-2 start"><li class="c1 c10 li-bullet-0"><span class="c0">If Chrome requests something, DT creates a span.</span></li><li class="c1 c10 li-bullet-0"><span class="c0">Server timing today has timing data. DT wants to provide a unique ID.</span></li><li class="c1 c10 li-bullet-0"><span>Trace Context wants to add trace context data to server timing.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1"><li class="c1 c2 li-bullet-0"><span class="c7">We want to provide an arbitrary string.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7">Charlie:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c7">Someone creates a GUID, this is sent to JS, and that is shared with whoever needs it. </span></li><li class="c1 c2 li-bullet-0"><span class="c7">Or does it need to be fed through other requests.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7">Alois:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c7">For now, this GUID wouldn’t need to be forwarded.</span></li><li class="c1 c2 li-bullet-0"><span class="c7">Two uses cases:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-2 start"><li class="c1 c10 li-bullet-0"><span class="c7">Browser starts a trace. (We’re not talking about this case)</span></li><li class="c1 c10 li-bullet-0"><span class="c7">Server Timing responds with trace context ID.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7">Charlie:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c7">Where would this data go in the server timing header? |description|?</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7">Alois:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c7">Systems we want to trace are becoming complicated.</span></li><li class="c1 c2 li-bullet-0"><span class="c7">Tracing providers have for a long time sent a header with a unique ID</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: What’s the parent ID if the browser sent a request?</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Alois</b>: Just a random ID.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Ryosuke</b>: What is a parent/child relationship in this context?</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c7">These are different hops?</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7"><b>Alois</b>: Yes.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Alois</b>: For each new request, you create a new parent ID.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: So the root of the tree would have a null parent ID?</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Alois</b>: No, it would be a GUID.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Alois</b>: You can do all this today.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c7">But if we have 3 nodes, one of which doesn’t understand the header this alls apart.</span></li><li class="c1 c2 li-bullet-0"><span class="c7">2 different implementations may not use the same header.</span></li><li class="c1 c2 li-bullet-0"><span class="c39">We’re proposing: </span><span class="c39">Trace-Parent, Trace-State</span><span class="c7">.</span></li><li class="c1 c2 li-bullet-0"><span class="c7">We just need to agree on the header, to improve co-ordination.</span></li><li class="c1 c2 li-bullet-0"><span class="c7">Trace-State contains additional information that individual monitoring providers require. (basically just a blob that gets propagated).</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: If the browser passes an ID, it’s the root of the tree.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Ryosuke</b>: What’s the benefit of including the browser?</span></li><li class="c1 c4 li-bullet-0"><span class="c7">?: If a browser is misbehaving we could identify this.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: So the benefit is that this information would be available to JS in the browser, and analytics could communicate their parent ID.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Alois</b>: folks already do this via Cookies</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: Does server timing allow you to address the same use-case?</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Ryosuke</b>: I understand the use-case, except for sending the header in the browser.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Alois</b>: To see the whole trace from end-to-end.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: But with server timing, you can do this without the browser initiating the tracing context.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Alois</b>: Example: Make 2 XHR requests.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c7">If the browser starts the transaction, we could associate the 2 requests.</span></li><li class="c1 c2 li-bullet-0"><span class="c7">Transaction-Id changes every request, Parent-Id doesn’t.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: Server timing should still be able to associate two requests. Make up your own parent id / trace id for the collection of these requests.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c7">I don’t think we want the browser to start sending an ID on these requests.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7">?: This is a somewhat different use case. Instead of just correlating with immediate request the browser made, we want to correlate with background services.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: You can do this already with server timing. ~ explanation ~</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Alois</b>: Maybe for resource timing, but we also want use timing etc.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Todd</b>: L3 User Timing will allow user-defined data. This doesn’t explicitly allow hierarchies, but you could construct them.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Ryosuke</b>: you should be able to produce hierarchy afterwards.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Alois</b>: How? Time-based correlation? This would be heuristic driven and not work well.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Todd</b>: </span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c7">Use case:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-2 start"><li class="c1 c10 li-bullet-0"><span class="c7">We’ve got some script, and we want to start a transaction, with a transaction ID.</span></li><li class="c1 c10 li-bullet-0"><span class="c7">We want to pass the transaction ID to network requests (XHR’s, fetch calls)</span></li><li class="c1 c10 li-bullet-0"><span class="c7">What about other kinds of requests? Scripts / css. Do they need the transaction ID?</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7"><b>Alois</b>: This is a bit fuzzy.</span></li><li class="c1 c4 li-bullet-0"><span class="c7">Todd:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-2 start"><li class="c1 c10 li-bullet-0"><span class="c7">What’s the lifetime of the transaction ID?</span></li><li class="c1 c10 li-bullet-0"><span class="c7">Script often comes from multiple sources.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7">Alois:</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c7">We want to enable either direction, starting from the server or the browser.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7"><b>Agreement</b>: Having the server send these headers makes sense.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Alois</b>: Standard server timing header for this.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: Or server timing convention.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Todd</b>: The concept of a transaction doesn’t make much sense, because work is interleaved.</span></li><li class="c1 c4 li-bullet-0"><span class="c7">?: It’s more of a user session ID.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: This would leak information.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Todd</b>: Yeah, this would need CORS protection.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: An anonymizer proxy wouldn’t strip these, make me less anonymized.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c7">Just looking at user timing, resource timing, server-timing, if you sort these, isn’t this enough?</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7">?: How do we correlate timings with a user?</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: If you include your tracing context when you upload timings, this should work.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Ryosuke</b>: The browser doesn’t have enough context to do this, but a framework should know.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Ted</b>: A framework should know.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Ryosuke</b>: Maybe a site would know.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-1 start"><li class="c1 c2 li-bullet-0"><span class="c7">This can’t really be a hierarchy</span></li><li class="c1 c2 li-bullet-0"><span class="c7">You could just report all of your performance at once to a server.</span></li></ul><ul class="c12 lst-kix_2bexye2j2yhs-0"><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: you could have a convention where JS applies a header.</span></li><li class="c1 c4 li-bullet-0"><span class="c7">?: Does resource timing indicate if an asset was served from a cache? I.e., not from the origin.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: No.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Todd</b>: NEL reports failing requests.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: If the failure is complete, reported by NEL, otherwise in resource timing.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Doug</b>: Successful requests also show up in NEL (sampled).</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: If you’re not sending a session ID, but are sending a request ID, that could fly.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Todd</b>: Then in JS, you’d combine your request IDs with your timing data, and upload that.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Todd</b>: You’ll still run into CORs preflight costs for every request.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: In order to make sure that the server is supposed to be exposed, for every non-safe request header, send an extra head request ahead of time, getting permission to send the non-safe headers.</span></li><li class="c1 c4 li-bullet-0"><span class="c7">?: But what if we can get them standardized?</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: Even if they’re standardized, getting them on the safe-list could still be hard.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: This should be opt in, with the bare minimum number of resources that you need.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Ted</b>: For same origin - this is fine.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Yoav</b>: For request headers, even without CORS, there are cases where we run into header name collisions.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Todd</b>: We aren’t saying this is impossible, we’re just saying it’s hard.</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Todd</b>: Was this the discussion you were looking for?</span></li><li class="c1 c4 li-bullet-0"><span class="c7"><b>Ted</b>: It sounds like we need to go try to leverage what’s available.</span></li><li class="c1 c4 li-bullet-0"><span class="c39"><b>Yoav</b>: I’m happy to help moving forward.</span></li></ul><p class="c1 c3"><span class="c0"></span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">(Scribe: cvazac)</span></p><h2 class="c6" id="h.419pqrf0s2sr"><span class="c19">Paint Timing</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/paint-timing/issues/29&amp;sa=D&amp;source=editors&amp;ust=1613252918962000&amp;usg=AOvVaw3CnvvUa1OkwaPvvRgI3PPW">Issue 29</a></span><span class="c0">:</span></p><p class="c1"><span class="c0"><b>Nicol&aacute;s</b>: what happens with invisible text, whitespace, or a slow loading web font</span></p><p class="c1"><span class="c0"><b>Tim</b>: we wouldn't want to trigger a paint event, if it was invisible, but in practice this is harder to do. So the question is, can we specify this in a way that a browser can ATTEMPT to exclude whitespace, but maybe it would fail. </span></p><p class="c1"><span class="c0"><b>Yoav</b>: does this expose a way to game the paint timing?</span></p><p class="c1"><span class="c0"><b>Tim</b>: this is already possible</span></p><p class="c1"><span class="c0"><b>Yoav</b>: does include invisible text change the gameability</span></p><p class="c1"><span class="c0"><b>Tim</b>: we aren’t worried about that, we are focused on well-meaning web devs. Paint is a lower bound anyway.</span></p><p class="c1"><span class="c0"><b>Benoit</b>: can we even define invisible text from a spec perspective</span></p><p class="c1"><span class="c0"><b>Rysokue</b>: if there’s no box, then its invisible… or collapsed whitespace. There are some clear cases. We keep metrics for init. painting. Turns out, we weren’t painting at the right time, because of whitespace in the page. If you have space between tags…. Ideally we’d have a concrete definition.</span></p><p class="c1"><span class="c0"><b>Tim</b>: strawman: if known whitespace chars….</span></p><p class="c1"><span class="c0"><b>Todd</b>: need to explicitly define whitespace</span></p><p class="c1"><span class="c0"><b>Tim</b>: we aren’t talking about an invisible D for one particular font</span></p><p class="c1"><span class="c0"><b>Todd</b>: are things that are characterized as whitespace, are those paints? CSS attributes applied to elements, does that control a paint. Or - what about size=0. There are a lot of corner cases here. </span></p><p class="c1"><span class="c0"><b>Gilles</b>: shouldn’t you know based on rendering pipeline, did I draw something or not?</span></p><p class="c1"><span class="c0"><b>Everyone</b>: yes in theory, hard in practice, disparate parts of the system</span></p><p class="c1"><span class="c0"><b>Tim</b>: we could specifically enumerate corner cases</span></p><p class="c1"><span class="c0"><b>Yoav</b>: is this really a problem in real life?</span></p><p class="c1"><span class="c0"><b>Rysokue</b>: yes!</span></p><p class="c1"><span class="c0"><b>Todd</b>: [summarizing webkit/Rysoke issue] - Did chrome also learn about wrong paint times based on your internal analytics?</span></p><p class="c1"><span class="c0"><b>Nicol&aacute;s</b>: in general, this isn’t a problem for chrome. We don’t think that changing definition of whitespace moves the needle that much. </span></p><p class="c1"><span class="c0"><b>Todd</b>: we don’t care about averages, we care about if anyone moves</span></p><p class="c1"><span class="c0"><b>Tim</b>: should we gather the data to find out how much this matters?</span></p><p class="c1"><span class="c0"><b>Todd</b>: yes</span></p><p class="c1"><span class="c0"><b>Tim</b>: ok, let’s by-hand analyze every page. We can only do a diff if we implement the “fixes”</span></p><p class="c1"><span class="c0"><b>Yoav</b>: will WPT help? Differences between start render and first paint?</span></p><p class="c1"><span class="c0"><b>Tim</b>: design this later, maybe first contentful paint might be better</span></p><p class="c1"><span class="c0"><b>Rysokue</b>: [to identify some of their whitespace cases]</span></p><p class="c1"><span class="c0"><b>Alex</b>: whitespace only drawing - we should definitely consider that. But, white or invisible text - that’s meaningful. The developer did that. We should report on that. </span></p><p class="c1"><span class="c0"><b>Alex</b>: what if there is no content?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span>Next item, </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/paint-timing/issues/20&amp;sa=D&amp;source=editors&amp;ust=1613252918964000&amp;usg=AOvVaw2ryH3mDBhoAUcd9svIvFfA">Issue #20</a></span><span class="c0"><b></b>: (clipped contents in first contextual paint?)</span></p><p class="c1"><span class="c0"><b>Yoav</b>: please describe this for us canvas-challenged folk</span></p><p class="c1"><span class="c0"><b>Tim</b>: we are talking about drawing to a canvas versus trying to draw to canvas</span></p><p class="c1"><span class="c0"><b>Todd</b>: [clarifying] if we paint to canvas, and it’s white…. that’s still content?</span></p><p class="c1"><span class="c0"><b>Rysokue</b>: because SVG is a vector format, determining…</span></p><p class="c1"><span><b>Rysokue</b>: we should just assume that canvas has a paint<br><b>Yoav</b>: empty canvas that gets drawn on later shouldn't be counted as a paint?<br><b>Everyone</b>: this is common<br><b>Markus</b>: firefox, we know about canvases that haven't been drawn to<br><b>Yoav</b>: yes, this isn't for SVG, other than gaming, and forget those people<br><br><br>Next issue, </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/paint-timing/issues/19&amp;sa=D&amp;source=editors&amp;ust=1613252918965000&amp;usg=AOvVaw07hZ_1QDCLwqD0jKsV2evz">#19</a></span><span class="c0">&nbsp;(exact timing of a navigation)<br><b>Nicol&aacute;s</b>: this is just a misunderstanding, probably just a misworning of the spec<br><b>Todd</b>: we can eliminate "before the navigation"....<br><b>Rysokue</b>: what would be the definition then? when the browser first rendered in this browsing context?<br><b>Dominic</b>: no, this doesn't work, context is created when you open new browsing context<br><b>Markus</b>: then how is the time origin defined?<br><b>Todd</b>: let's look at hr-time spec! section #3<br><b>Yoav</b>: [reading spec aloud]<br><b>Todd</b>: technically, let's just point to this hr-time spec<br><b>Nicol&aacute;s</b>: our convention is: diff between now and origin, .....<br><b>Todd</b>: but when do we record this, per navigation? first navigation?<br><b>Yoav</b>: first rendered after what? first after time origin is zero?<br><b>Todd</b>: is it navigate? (link to hr-time)</span></p><p class="c1"><span class="c0"><b>Todd</b>: I assert that first paint needs to be relative to navigation (HTML5)</span></p><p class="c1"><span class="c0"><b>Dominic</b>: just ecluse first two cases?</span></p><p class="c1"><span class="c0"><b>Todd</b>: i’m concerned about unload case</span></p><p class="c1"><span class="c0"><b>Rysokue</b>: we are getting to the can of worms, navigation is complicated, to pinpoint start render, for different browsers) [is going to be a problem].</span></p><p class="c1"><span class="c0"><b>Yoav</b>: we are trying to determine WHEN we want to measure first-paint, are we able to identify the lower bound?</span></p><p class="c1"><span class="c0"><b>Todd</b>: the trigger - next render after this - is going to be first paint</span></p><p class="c1"><span class="c0"><b>Rysokue</b>: that’s too early</span></p><p class="c1"><span class="c0"><b>Alex</b>: could be animating from previous page</span></p><p class="c1"><span class="c0"><b>Gilles</b>: [suggestion]</span></p><p class="c1"><span class="c0"><b>Todd</b>: can’t see timeOrigin from previous page</span></p><p class="c1"><span class="c0"><b>Dominic</b>: don’t say any paint at all, paint on the document</span></p><p class="c1"><span class="c0"><b>Todd</b>: primary document first paint event</span></p><p class="c1"><span class="c0"><b>Rysokue</b>: need to check that, is this rendering happening for THIS document that we just navigated to</span></p><p class="c1"><span class="c0"><b>Alex</b>: this could be a good starting time, but we will need to define when we start painting the new page, as having come from data received…</span></p><p class="c1"><span class="c0"><b>Dominic</b>: if you are updating the rendering for the document that i care about….</span></p><p class="c1"><span class="c0"><b>Todd</b>: so all IFRAMEs get their own first paints?</span></p><p class="c1"><span class="c0"><b>Everyone</b>: yes. </span></p><p class="c1"><span class="c0"><b>Rysokue</b>: so that needs to be fixed.</span></p><p class="c1"><span class="c0"><b>Tim</b>: proposal: first paint, in the document we care about, after time origin is set.</span></p><p class="c1"><span class="c0"><b>Everyone</b>: yes. </span></p><p class="c1 c3"><span class="c0"></span></p><h1 class="c33" id="h.9ig59qayr07e"><span class="c28"><br>Friday Minutes</span></h1><h2 class="c6" id="h.au62emvhe0ay"><span class="c19">Morning Agenda:</span></h2><ul class="c12 lst-kix_6bh46ir5vr6z-0 start"><li class="c1 c4 li-bullet-0"><span class="c0">Preload</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Input Timing</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Prefetch</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Long Tasks</span></li></ul><p class="c1 c3"><span class="c0"></span></p><h2 class="c6" id="h.u09vfyy2ki2u"><span class="c19">Preload</span></h2><p class="c1"><span class="c0"><b>Kinuko</b>: srcset / sizes for images</span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/preload/issues/120&amp;sa=D&amp;source=editors&amp;ust=1613252918967000&amp;usg=AOvVaw0K2ha8TAzYw4KNO1AKSThD">https://github.com/w3c/preload/issues/120</a></span></p><p class="c1"><span class="c0"><b>Kinuko</b>: For responsive images</span></p><p class="c1"><span><b>Yoav</b>: &lt;live coding, nothing can go wrong here&gt; </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/preload/issues/120%23issuecomment-433307060&amp;sa=D&amp;source=editors&amp;ust=1613252918967000&amp;usg=AOvVaw2VHJ3J6Nx0QlaQIODXVNwQ">https://github.com/w3c/preload/issues/120#issuecomment-433307060</a></span></p><p class="c1"><span class="c0"><b>Kinuko</b>: Attributes like imagesrcset=”” and imagesizes=””</span></p><p class="c1"><span class="c0"><b>Yoav</b>: In these cases all images are representative of the same image, just in different resolutions</span></p><p class="c1"><span><b>Kinuko</b>: This won’t capture &lt;picture&gt; tag </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/preload/issues/131&amp;sa=D&amp;source=editors&amp;ust=1613252918967000&amp;usg=AOvVaw1fiUe7KhYcQTRVdAUr1TpC">cases</a></span><span class="c0">&nbsp;though</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: I presume this would have the same handling as the &lt;img&gt; element</span></p><p class="c1"><span class="c0"><b>Kinuko</b>: yes</span></p><p class="c1"><span class="c0"><b>Yoav</b>: In markup this could work, but if Link tag is delivered via HTTP header, the browser possibly doesn’t yet know the viewport dimensions, so I’d “hold on” to the preload until the dimensions are known</span></p><p class="c1"><span class="c0"><b>Gilles</b>: Could this still be fetched prior to HTML parsing on a mobile device because the viewport is better known (fixed)?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Markup such as &lt;meta viewport&gt; can affect the viewport size</span></p><p class="c1"><span class="c0"><b>Tim</b>: Having the viewport tag appear before the preload tag might cause developer or browser ergonomic problems</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Processing model could mention that preloads might not be triggered until the browser has finished receiving the bytes of the &lt;head&gt; (so any viewport tags can be read)</span></p><p class="c1"><span class="c0"><b>Yoav</b>: No major objections with this, seems like this is a use-cases we should tackle, knowing there are viewport issues we need to address</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Yoav</b>: Brings us to the other gap regarding images with preload, &lt;picture&gt;</span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/preload/issues/131&amp;sa=D&amp;source=editors&amp;ust=1613252918968000&amp;usg=AOvVaw1HQ8mIqZcTSzsvvhg3JdS5">https://github.com/w3c/preload/issues/131</a></span></p><p class="c1"><span class="c0"><b>Yoav</b>: Picture’s sub-elements, whichever is the first sub-element that matches (media attribute), triggers the actual download</span></p><p class="c1"><span class="c0"><b>Yoav</b>: One way is to have your &lt;link rel=preloads&gt; have mutually exclusive media=”” queries so the browser will only pick the “one” that matches. &nbsp;Puts a lot of burden on developers. &nbsp;Not easy to do.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: &lt;picture&gt; also allows type=”” attributes (e.g. for webp), which isn’t in the &lt;link rel=preload&gt; case</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Alternative proposal is to somehow declare multiple preloads as a “group”, which the browser picks only one, in a similar way to how the browser picks a &lt;picture&gt; element</span></p><p class="c1"><span class="c0"><b>Markus</b>: Could we have a new top-level grouping element like &lt;picture&gt; is?</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: This won’t work for Link HTTP header-based preload</span></p><p class="c1"><span class="c0"><b>Todd</b>: Could we put the actual element in the head, with some sort of attribute saying “don’t use this yet”? &nbsp;Not sure this a strong option</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: &lt;imgs&gt; are more straightforward because it will always be shown, whereas &lt;picture&gt; elements can be affected by orientation, viewport, etc. &nbsp;Not sure developers will be able to understand how to best configure their preloads in &lt;picture&gt; cases</span></p><p class="c1"><span class="c0"><b>Yoav</b>: One use-case is for hero images, which might be in a &lt;picture&gt; element, and they want this image kicked off earlier</span></p><p class="c1"><span class="c0"><b>Gilles</b>: Very similar use-case for Wikipedia logo</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: Developers could add an invisible/1px div that has the same &lt;picture&gt; element in the top of the document so that it’s loaded earlier. &nbsp;Avoids duplicating everything &lt;picture&gt; element does in the &lt;link rel=preload&gt; element.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Sounds like we all think this is complex idea. &nbsp;Are there concrete use-cases from customers?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Opinion is we should go ahead with srcset for imgs, punt on this for now, until there are more concrete use-cases. &nbsp;Developers can use media-query hacks today.</span></p><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/w3c/preload/issues/131%23issuecomment-433314755&amp;sa=D&amp;source=editors&amp;ust=1613252918969000&amp;usg=AOvVaw3lM8-UUrh1x5XupoV0jti_">https://github.com/w3c/preload/issues/131#issuecomment-433314755</a></span></p><h2 class="c6" id="h.mwbm7by49684"><span class="c19">Input Timing</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1pxx3qMLqzcdtJ_o46XLCgE3uCSI0X_jwgqh-subIgWY/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918970000&amp;usg=AOvVaw0ObM_WEvSC9jwu9ymxDv_v">https://docs.google.com/presentation/d/1pxx3qMLqzcdtJ_o46XLCgE3uCSI0X_jwgqh-subIgWY/edit#slide=id.p</a></span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Proposal for Input Timing (was previously called Event Timing)</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Timing about input events, better name</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Provide web developers and analytics providers a way to measure input latency</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Can do today, not performant or reliable</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: &lt;examples in slides&gt;</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Measures mouse, point, touch, kb, input, wheel, composition events</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Expose slow inputs (event handler duration), how long UA took to respond to input event</span></p><p class="c1"><span class="c0"><b>Yoav</b>: How does that work for animated things, like a flyout. &nbsp;Does it measure the “first” time it is seen, or full animation?<br><b>Nicolás</b>: First time it is painted</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Measure queuing time (HW input vs when first event handler is called)</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Slow events &gt; 52ms</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Future: provide event.measureUntil() for async work</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Security: Same accuracy as performance.now()</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Rendering duration is rounded (multiple of 8)</span></p><p class="c1"><span class="c0"><b>Todd</b>: Is this the rendering timestamp (main thread) or the graphics-card display timestamp?</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: As close as possible to when pixels are displayed</span></p><p class="c1"><span class="c0"><b>Todd</b>: There’s talk of a post-render-steps callback, would that enable more attacks since that would give more precision</span></p><p class="c1"><span class="c0"><b>Tim</b>: Had security review, but can sync with them again based on that</span></p><p class="c1"><span class="c0"><b>Todd</b>: Combined with PaintTiming, can this help us understand the total input+display latency</span></p><p class="c1"><span class="c0"><b>Tim</b>: This is focused on just slow input events, not all events</span></p><p class="c1"><span class="c0"><b>Tim</b>: Lower-level primitive would be all paint events + all input events, but we can’t expose all of that for privacy and security</span></p><p class="c1"><span class="c0"><b>Charlie</b>: I’d also like a similar thing for the work based off the output of XHRs (e.g. DOM updates)</span></p><p class="c1"><span class="c0"><b>Markus</b>: Likes this a lot, we want to measure from hardware timestamp to display. &nbsp;Rendering timestamps we get are from the start of the timeline and pages can take a long time (e.g. 200+ms on complex pages), want to make sure that duration is reflected</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: Don’t want to expose the timestamp of when rendering is done (security concerns)</span></p><p class="c1"><span class="c0"><b>Markus</b>: What happens if input event doesn’t cause any visual changes.</span></p><p class="c1"><span><b>Nicolás</b>: We want to still have the event measured, with a display timestamp “close to” the time when rendering might have happened (security concerns)</span></p><p class="c1"><span><b>Falken</b>: Make this a generic PerformanceEventTiming, esp for service worker events? &nbsp;Other examples included fetch, background API, etc</span></p><p class="c1"><span class="c0"><b>Tim</b>: Spec is focused on input events right now, but this could be extended in the future to other events</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Could keep EventTiming as a parent interface for IDL, with InputTiming implemented as</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Not enough to expose entries for slow inputs, need to know % of overall total</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: For each event time, number of events dispatched</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: &lt;IDL explainer&gt;</span></p><p class="c1"><span class="c0"><b>Tim</b>: How to expose total event counts: as a # on the slow event (which means you’ll not get info about non-slow events at the end) or on something like performance.eventCounts which might be slightly off due to async nature of updating</span></p><p class="c1"><span class="c0">Yoav+others: Slight error sounds better than blackhole of missing events at the end</span></p><p class="c1"><span class="c0"><b>Todd</b>: Why async update?</span></p><p class="c1"><span class="c0"><b>Tim</b>: Some events will be handled on the main thread by JS, others not, and both need to be counted in overall total</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Want to expose first input latency. &nbsp; First input is always slowest. &nbsp;Don’t show trivial inputs, so only key down, mouse down, pointer down+up, click</span></p><p class="c1"><span class="c0"><b>Nicolás</b>: Exposed as a single observable event always</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Can I get the thoughts of UAs on desire to implement?</span></p><p class="c1"><span class="c0">&lt;UAs discuss there’s not strong opposition&gt;</span></p><p class="c1"><span class="c0">Mozilla and Microsoft folks seems fairly enthusiastic about tackling the use case</span></p><p class="c1"><span class="c0">Apple says it doesn’t look awful, but early to commit.</span></p><p class="c1"><span class="c0"><b>Tim</b>: Discusses why not just putting this information in Long Tasks (no concept of HW input timestamp, correlation with rendering, etc)</span></p><h2 class="c6" id="h.oqrg86hg3ycz"><span class="c19">Prefetch</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/whatwg/html/pull/4115&amp;sa=D&amp;source=editors&amp;ust=1613252918973000&amp;usg=AOvVaw1dCysFHQirlsLnXGwuOQYT">https://github.com/whatwg/html/pull/4115</a></span></p><p class="c1"><span class="c0"><b>Yoav</b>: Looking into better defining prefetch</span></p><p class="c1"><span class="c0"><b>Yoav</b>: A couple questions came along</span></p><p class="c1"><span class="c0"><b>Yoav</b>: 1. How should prefetch behave when cache is double-keyed</span></p><p class="c1"><span><b>Yoav</b>: 2. How should prefetch behave with Service Workers (don’t know which SW will service them)</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Need to set a bunch of flags (e.g. no-referrer, no-service-worker), etc. &nbsp;Do we re-use the “keepalive” flag (used for Beacon), which has some other implications like not caring for the response</span></p><p class="c1"><span class="c0"><b>Youenn</b>: While there are similarities to needs of keepalive flag, there are some differences like 64kb limit, what to do with response if there’s no current browser context, etc</span></p><p class="c1"><span class="c0"><b>Yoav</b>: New “speculative” flag, which could apply different restrictions</span></p><p class="c1"><span class="c0"><b>Yoav</b>: RE: ServiceWorker questions, should we have different behavior in double-keyed cache world for what goes to SW vs not</span></p><p class="c1"><span class="c0"><b>Todd</b>: Can this be solved with some “prerender” cases where the core document is fetched and the UA decides if it wants to drive the parser, see preload tags, etc</span></p><p class="c1"><span>Falkenhagen</span><span class="c0"><b></b>: How do you know if the prefetch is for a main resource or a sub-resource</span></p><p class="c1"><span class="c0"><b>Yoav</b>: We don’t know today, as=”document”</span></p><p class="c1"><span class="c0"><b>Falkenhagen</b>: There’s a valid use case for prefetching a worker as well</span></p><p class="c1"><span class="c0"><b>Alex</b>: There are use cases for subresources in same-domain, but concerns about different domain in terms of privacy</span></p><p class="c1"><span class="c0"><b>Youenn</b>: There are also concerns that developers will not get it right, so we may prefetch resources and they will not be used. Better to avoid footguns. Better to restrict prefetch to main document, and see later.</span></p><p class="c1"><span class="c0"><b>Kinuko</b>: Browsers that don’t implement double-keying may prefetch subresources, and double keyed caches can just ignore them.</span></p><p class="c1"><span class="c0"><b>Youenn</b>: That runs a risk of forking content. We may not want that.</span></p><p class="c1"><span class="c0"><b>Alex</b>: There’s still a valid use case for subresources for same-origin. So we definitely need as=document or something similar. If we need to skip service workers, we’re doing the wrong thing.</span></p><p class="c1"><span class="c0"><b>Tim</b>: Can be confusion if SW is not always hit</span></p><p class="c1"><span class="c0"><b>Kinuko</b>: Can’t we have SW for same origin subresources</span></p><p class="c1"><span class="c0"><b>Yoav</b>: not sure what the scope would be</span></p><p class="c1"><span class="c0"><b>Ben</b>: This smells like Foreign Fetch and risky in terms of privacy. The conservative case would be to skip the SW for anything cross-origin. Concerned with letting prefetch running JS on their own origin. Even in the non-double-keyed-cache case. Would also apply to Chrome when disabling third party cookies.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: That changes things, so we should probably skip SW for all cross-origin navigations</span></p><p class="c1"><span class="c0"><b>Ben</b>: We could apply same policies like storage partitions, etc, but seems to complicate the cases here. &nbsp;Conservative is to bypass SW.</span></p><p class="c1"><span class="c0"><b>Alex</b>: Concerned no matter what outcome, will cause a mess. &nbsp;w/ SW a bunch of SW maybe aren’t needed or security implications. &nbsp;w/ no SW, and if developer only wanted to load something via SW now they can’t.</span></p><p class="c1"><span class="c0"><b>Ben</b>: The cross origin subresource case shouldn’t really exist</span></p><p class="c1 c3"><span class="c0"></span></p><h2 class="c6" id="h.78om3btyjjny"><span class="c19">Scheduling API</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/spanicker/main-thread-scheduling&amp;sa=D&amp;source=editors&amp;ust=1613252918975000&amp;usg=AOvVaw24HMsWgqsg6u6MZ7aWaugk">proposal</a></span><span>&nbsp;/ </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/12lkTrTwGedKSFqOFhQTsEdcLI3ydRiAdom_9uQ2FgsM/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918975000&amp;usg=AOvVaw3eulc_5lXvqQ_qfMQJq_Sz">slides</a></span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Shubhie</b>: websites need to be responsive, primary issue comes down to script executing blocking responsives (see slides).</span></p><p class="c1"><span class="c0">Apps and sites that build their own scheduling libraries have achieved good performance that way.</span></p><p class="c1"><span class="c0">Schedulers are build on top of native APIs (like rAF) and have built-in priorities.</span></p><p class="c1"><span class="c0">Schedulers have to yield frequently *just in case* but they'd rather not have to yield if they had better signals from the browser.</span></p><p class="c1"><span class="c0">...</span></p><p class="c1"><span class="c0"><b>Tim</b>: ember uses microtasks for it's scheduler, how does that work since it can't yield?</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: they primarily use it for ordering</span></p><p class="c1"><span class="c0">...</span></p><p class="c1"><span class="c0"><b>Tim</b>: what does coordinate mean in the context of a scheduler?</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: handing rendering, pending fetches, input etc. low priority xhr responses don’t preempt my ongoing high priority work</span></p><p class="c1"><span class="c0">…</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: what's needed from the platform</span></p><p class="c1"><span class="c0">...since there's been alignment on handling of rAF, was there agreement on handling of input handlers cross-browser?</span></p><p class="c1"><span class="c0"><b>Chris</b>: no agreement on input scheduling yet…</span></p><p class="c1"><span>smaug</span><span class="c0"><b></b>: In some cases you want input to run before rAF</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: if rAF and input handlers are properly aligned cross-browser, that would make defining a scheduler easier.</span></p><p class="c1"><span class="c0">…</span></p><p class="c1"><span class="c0">default priority slide</span></p><p class="c1"><span class="c0"><b>Tim</b>: is before work before next frame what we want for "default priority"?</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: Apps can't use rIC in some cases due to starvation, rAF</span></p><p class="c1"><span class="c0"><b>Tim</b>: postMessage is an alternative to setTimeout(0)</span></p><p class="c1"><span class="c0"><b>Chris</b>: that's a platform hack, why not setImmediate?</span></p><p class="c1"><span class="c0"><b>Yoav</b>: idle until urgent pattern for setTimeout</span></p><p class="c1"><span class="c0"><b>Phil</b>: there could be IUU with different priorities</span></p><p class="c1"><span class="c0"><b>Chris</b>: priorities could get upgraded</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: what new primitives should we add to the platform to handle these use cases?</span></p><p class="c1"><span class="c0">Option A:</span></p><p class="c1"><span class="c0">A unified API for posting work + sematic priorities</span></p><p class="c1"><span class="c0">Users can create their own task queue</span></p><p class="c1"><span class="c0">Option B:</span></p><p class="c1"><span class="c0">Standardized JS Scheduler</span></p><p class="c1"><span class="c0"><b>Yoav</b>: a high level API would be useful, so would underlying APIs</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: they've not necessarily mutually exclusive</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: &lt;top feature requests slide&gt;</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: who is asking for these features?</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: Google Maps, Ember, React</span></p><p class="c1"><span class="c0"><b>Tim</b>: game developers are asking for it. They can't hit 60fps, so they degrade</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: developers also want a way for promises to yield.</span></p><p class="c1"><span class="c0"><b>Nate</b>: agree</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: how would you break up promises into multiple tasks?</span></p><p class="c1"><span class="c0"><b>Nate</b>: more what we want is a way to break up promises chains and yield to input</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: this would require a change to JS via TC39</span></p><p class="c1"><span class="c0"><b>Nate</b>: most developers don't understand enough about the event loop to write code that yields to input well.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: and arguably they shouldn't have to</span></p><p class="c1"><span class="c0"><b>Tim</b>: it's possible to polyfill microtasks that yield</span></p><p class="c1"><span class="c0"><b>Phil</b>: with async functions it's not easy to polyfill without a build step</span></p><p class="c1"><span class="c0">Priority hints</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: what are the use cases?</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: maps wanted this for fetching tiles</span></p><p class="c1"><span class="c0"><b>Nate</b>: logs shouldn't block other fetches</span></p><p class="c1"><span class="c0"><b>Todd</b>: after multiple fetches do we want priority on which callback runs first?</span></p><p class="c1"><span class="c0"><b>Chris</b>: no, priority for network resource use. But important to consider the resolution priority as well</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: what is the facebook use case?</span></p><p class="c1"><span class="c0"><b>Nate</b>: fetch a component that's not visible on the screen, this is lower priority at the time</span></p><p class="c1"><span class="c0"><b>Chris</b>: there's a fear of putting something at low priority because you can't always easily upgrade.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: yes, reprioritizing is a key feature</span></p><p class="c1"><span class="c0"><b>Alex</b>: changing the priority of in-flight or queued network requests is hard</span></p><p class="c1"><span class="c0"><b>Yoav</b>: this may become easier with H2</span></p><p class="c1"><span class="c0"><b>Benoit</b>: servers would test reprioritization logic if the API existed</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: should we poll the group for the need of these APIs?</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: there are different concerns being discussed here, which specifically are we talking about</span></p><p class="c1"><span class="c0"><b>Nate</b>: breaking part promise chains is critical for us</span></p><p class="c1"><span class="c0"><b>Chris</b>: non-rendering, high priority work, is important but shouldn't need to use rAF (but still yield)</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: user-blocking and default priority are the main ones we need</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: network request priority and handler priority cannot necessarily be inferred by the browser</span></p><p class="c1"><span class="c0"><b>Yoav</b>: priority hints already help with network priority</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: yes, ultimately it's about providing hints to the browser.</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: there may be priority inheritance problems, high priority request may not imply high priority response or callback</span></p><p class="c1 c3"><span class="c0"></span></p><h2 class="c6" id="h.hqr32j2qt662"><span class="c19">hasPendingUserInput</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/tdresser/should-yield/blob/master/README.md&amp;sa=D&amp;source=editors&amp;ust=1613252918980000&amp;usg=AOvVaw0kXtwln0TRMD8NRJn0QLj8">proposal</a></span><span>&nbsp;/ </span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1giv9r-2Vy5G8FGAlgBFQU05FlAZKTmp8CF5otFw3QmQ/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918980000&amp;usg=AOvVaw3I8-81qGI0QVpB0HvZf1qj">slides</a></span><span>&nbsp;</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Tim</b>: this was previously presented as shouldYield…</span></p><p class="c1"><span class="c0">[slides]...</span></p><p class="c1"><span class="c0"><b>Tim</b>: how should we handle long tasks in a world where a developer is using hasPendingUserInput</span></p><p class="c1"><span class="c0"><b>Phil</b>: input timing solves this problem to some degree</span></p><p class="c1"><span class="c0"><b>Benoit</b>: is there a danger of yielding to the wrong task?</span></p><p class="c1"><span class="c0"><b>Tim</b>: yes, once you yield who gets to go next is still a problem:</span></p><p class="c1"><span class="c0"><b>Benoit</b>: a scheduler would help with that</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: why did the timestamp get removed? (time input has been pending)</span></p><p class="c1"><span class="c0"><b>Tim</b>: are there use cases? Isn't input always the highest priority?</span></p><p class="c1"><span class="c0"><b>Nate</b>: there are some cases where you need to finish work before yielding.</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: events like mousemove and mousedown will likely have different priorities</span></p><p class="c1"><span class="c0"><b>Todd</b>: originally proposed time, but maybe wait until good use cases arrive</span></p><p class="c1"><span class="c0"><b>Alex</b>: this could quickly lead to API bloat</span></p><p class="c1"><span class="c0"><b>Yoav</b>: maybe also include a reason for yield</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: what about a mouse move with a hover effect, it still may be lower priority</span></p><p class="c1"><span class="c0"><b>Tim</b>: sometimes you have work that should or should not block the next frame, and you might want to know if input is pending before making that decision.</span></p><p class="c1"><span class="c0"><b>Chris</b>: task priorities can take that into account</span></p><p class="c1"><span class="c0"><b>Tim</b>: this proposal is a low level solution that would make things better than they are today, higher-level things could be better but are harder to implement</span></p><p class="c1"><span class="c0">...concern that the more we let UAs prioritize the higher chance we have to interop issues</span></p><p class="c1"><span><b>Tim</b>: we could take some time to look into what a more complex API might look like if there's concern with this API</span></p><p class="c1"><span class="c0"><b>Smaug</b>: have we defined what pending user input means?</span></p><p class="c1"><span class="c0"><b>Tim</b>: we have some spec work for this for sure</span></p><p class="c1"><span class="c0"><b>Benoit</b>: could this lead to yielding multiple times per frame?</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: on mac there's at most 1 event type per frame in most cases (mousemove)</span></p><p class="c1 c3"><span class="c0"></span></p><h2 class="c6" id="h.ebavbalffaag"><span class="c19">FetchEvent Worker Timing</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/wanderview/fetchevent-worker-timing/blob/master/explainer.md&amp;sa=D&amp;source=editors&amp;ust=1613252918982000&amp;usg=AOvVaw0eSSjrJ-r4ZpA0i7KERFPU">proposal</a></span><span class="c0">&nbsp;</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Ben</b>: for simple FetchEvents, what we already expose in resource timing is sufficient, but for complex SW responses with strategies that read from IDB, etc we can't capture that time.</span></p><p class="c1"><span class="c0">Like we do with server timing, we could have a worker timing header that we can write artibrary times.</span></p><p class="c1"><span class="c0"><b>Npm</b>: why isn't user timing sufficient?</span></p><p class="c1"><span class="c0"><b>Ben</b>: it doesn't get associated with the particular request</span></p><p class="c1"><span class="c0"><b>Nate</b>: you can also have multiple tabs accessing the same SW, and you don't always know which one, so you need to match it</span></p><p class="c1"><span class="c0"><b>Yoav</b>: we could have a fetch ID to make the matching, but that’s far-future and worse ergonomics</span></p><p class="c1"><span class="c0"><b>Nate</b>: we try to do this measurement now, and it's very hard to get it right. This would be very useful</span></p><p class="c1"><span class="c0">…</span></p><p class="c1"><span class="c0"><b>Markus</b>: having a common ID for fetch events would be very useful for lots of reason, similar to yesterday’s discussion with the Distributed Tracing WG</span></p><p class="c1"><span class="c0"><b>Ben</b>: some responses are not generated by servers...mutating headers in a SW is probably not an option for this solution</span></p><p class="c1"><span class="c0"><b>Nate</b>: sometimes you don't respond from a SW at all, but you still want to measure the perf impact</span></p><p class="c1"><span class="c0"><b>Yoav</b>: some responses are opaque and you can't modify them</span></p><p class="c1"><span class="c0"><b>Ryosuke</b>: is this exposed in the fetch response?</span></p><p class="c1"><span class="c0"><b>Ben</b>: the implementation of adding it to the fetch event vs. passing it to the fetch event can be handled in an issue, will follow up.</span></p><p class="c1"><span class="c0"><b>Ben</b>: for cases where you want to measure what happens after event.respondWith, you could have the perf entry delayed until after the promise resolves, and it would still add timing data to that fetch</span></p><p class="c1"><span class="c0">...User timing L3 could also handle this case if we can attach metadata to an entry</span></p><p class="c1"><span class="c0"><b>Charlie</b>: I like this proposal as it solves a lot of the same issues I dealt with in server timing (e.g. duplicate names)</span></p><p class="c1"><span class="c0"><b>Ben</b>: I plan to do some implementation and experimentation in Chrome in Q4</span></p><p class="c1 c3"><span class="c0"></span></p><a id="id.kindj2bjow4h"></a><h2 class="c6" id="h.7ovp89isbszf"><span class="c19">In flight resource request</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1gJNE9agv4bvunNkcc8LJeDAxgpdcjJnUedIe3D_RlMY/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918983000&amp;usg=AOvVaw0_xzMpwwI6R_gRanRm_5ip">slides</a></span></p><p class="c1"><span class="c0"><b>Npm</b>: We’ve discussed inflight requests before. We want to expose information about requests that weren’t yet completed.</span></p><p class="c1"><span class="c0">Use cases:</span></p><ul class="c12 lst-kix_n1vgv7b27bdi-0 start"><li class="c1 c4 li-bullet-0"><span class="c0">Allowing for find out if the network is idle and knowing how many requests there are</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Create a busy network indicator</span></li></ul><p class="c1"><span class="c0">Goal is to arrive to consensus on the need and decide on the shape of the API. Will present a proposal</span></p><p class="c1"><span class="c0">Adding a ResourcetimingUpdate interface that notifies when attributes have been computed. Notifying only attributes that have reached their final states. So this will notify the beginning and the end of each network request.</span></p><p class="c1"><span class="c0">In the future we can try to split requests according to redirects and could expose more details.</span></p><p class="c1"><span class="c0">ResourceTimingUpdate includes entryType and attributesUpdated.</span></p><p class="c1"><span class="c0">Fetch integration will need to happen as part of the overall ResourceTiming integration.</span></p><p class="c1"><span class="c0">The fact that PO delivers entries sync means that some use cases (rendering busy widgets) may suffern from lags</span></p><p class="c1"><span class="c0"><b>Alternative</b>: Modify PerformanceResourceTiming</span></p><p class="c1"><span class="c0">Not backwards compatible and may be confusing to current users.</span></p><p class="c1"><span class="c0">Alternative 2: Add event listeners when a request begins or when response received. Downside is that it would encourage early registration of event listeners.</span></p><p class="c1"><span class="c0">Alternative 3: Create a FetchObserver</span></p><p class="c1"><span class="c0">Could receive timing information for request/response, but not modify them (so not FetchEvent)</span></p><p class="c1"><span class="c0"><b>Tim</b>: So this would recreate the buffering logic of PO in the Fetch spec.</span></p><p class="c1"><span class="c0"><b>Npm</b>: yes, we would need to do that</span></p><p class="c1"><span class="c0"><b>Ben</b>: I’d be very hesitant to do that</span></p><p class="c1"><span class="c0"><b>Yoav</b>: Have you considered alternative 1, but with an opt-in? Notifying the observer twice per each entry? How does it work for navigation?</span></p><p class="c1"><span class="c0"><b>Tim</b>: You need to poll it, you don’t get updates</span></p><p class="c1"><span class="c0"><b>Yutaka</b>: This will expose when requests fail. Would it be OK?</span></p><p class="c1"><span class="c0"><b>Tim</b>: We would now need to expose failing requests, and that may be security sensitive</span></p><p class="c1"><span class="c0"><b>Phil</b>: It doesn’t look like most use-cases need such a complex API. Have we looked into just exposing the number of inflight requests?</span></p><p class="c1"><span class="c0"><b>Tim</b>: Won’t answer use-cases that want to filter requests by criteria (e.g. pending images, etc). We can’t really expose it in a single number</span></p><p class="c1"><span class="c0"><b>Phil</b>: Feels like we’re trying to force RT to be high-priority</span></p><p class="c1"><span class="c0"><b>Todd</b>: Use-cases are not sufficiently spelled out</span></p><p class="c1"><span class="c0"><b>Nic</b>: We have 2 primary use-cases:</span></p><ul class="c12 lst-kix_iq68aatvclj5-0 start"><li class="c1 c4 li-bullet-0"><span class="c0">Single page app - want to track soft navs, and want to know how long it took for them to be done. Currently use mutation observer, add event handlers and essentially build our own onload timestamp. So instead of being notified on downloads directly, we track elements that get added to the page that trigger downloads. We pay extra attention to user visible resources, so a single number may not be sufficient (but better than using MO all over the place).</span></li></ul><p class="c1"><span class="c0"><b>Todd</b>: Would element timing solve your use case?</span></p><p class="c1"><span class="c0"><b>Nic</b>: That would require the application to do more of their own instrumentation, which they won’t</span></p><p class="c1"><span class="c0"><b>Todd</b>: So you’re trying to hook that into existing frameworks?</span></p><p class="c1"><span class="c0"><b>Nic</b>: Yeah</span></p><p class="c1"><span class="c0">The second use case is to polyfill TimeToInteractive. We’re not using network idleness as a signal because it’s complex, but if we had the info we would use it.</span></p><p class="c1"><span class="c0"><b>Todd</b>: And why can’t you wait</span></p><p class="c1"><span class="c0"><b>Nic</b>: We don’t know when to stop waiting, because we don’t know how many things are outstanding</span></p><p class="c1"><span class="c0"><b>Todd</b>: Want to make sure that the use-cases are well defined</span></p><p class="c1"><span class="c0"><b>Yoav</b>: So Phil’s suggestion is an upper bound, but won’t cover long standing polling requests which you may not care about</span></p><p class="c1"><span class="c0"><b>Charlie</b>: So request start and end is enough?</span></p><p class="c1"><span class="c0"><b>Tim</b>: If we add more stuff to RT, we’d expect them to show up dynamically</span></p><p class="c1"><span class="c0"><b>Nic</b>: If the observer is too late to arrive, that may delay our decision to act on that info. But MutationObservers are not different.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Using the network as the measure, you want to notifications on start and stop. You don’t want to poll it, so there’s room to iterate on the API</span></p><p class="c1"><span class="c0"><b>Tim</b>: There’s inherent tension between buffering and async delivery here.</span></p><p class="c1"><span class="c0"><b>Rniwa</b>: why buffering?</span></p><p class="c1"><span class="c0"><b>Tim</b>: Imagine a really large resource. May be buffered really late</span></p><p class="c1"><span class="c0"><b>Yutaka</b>: which events?</span></p><p class="c1"><span class="c0"><b>Tim</b>: Events when the state of a resource request changes. There’s a function call which says “give me information about resource requests” and events that fire as a result</span></p><p class="c1"><span class="c0"><b>Npm</b>: Maybe a function that enables you to query the current state of the network.</span></p><p class="c1"><span class="c0"><b>Yoav</b>: would we need to poll in that case? Maybe not as PO will fire if the network is not idle</span></p><p class="c1"><span class="c0"><b>Tim</b>: Sounds concrete enough that we can draft yet another proposal</span></p><p class="c1"><span class="c0"><b>Matt</b>: What happens if a request went to SW and SW responded with a Fetch event? Is that a new resource request</span></p><p class="c1"><span class="c0"><b>Npm</b>: that would be in progress</span></p><p class="c1"><span class="c0"><b>Nic</b>: we need failed network requests to PO as well, otherwise we will wait forever</span></p><p class="c1"><span>Yutaka/</span><span class="c0"><b>Ben</b>: no-cors CSS subresources would be invisible here as well, if they are invisible in RT and SW</span></p><p class="c1 c3"><span class="c0"></span></p><h2 class="c6" id="h.yc6fqopvm51w"><span class="c19">Task Worklet</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/12QX9k2yXFngwbEIm4fA4KJ4HQoiiPa12oBJSisx6FRA/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918987000&amp;usg=AOvVaw3BrthokN8afWDvqzgJHefE">slides</a></span></p><p class="c1"><span class="c0"><b>Shubhie</b>: been looking as using worklets to move script work off main thread.</span></p><p class="c1"><span class="c0"><b>Trying to tackle the use cases of moving heavy work</b>: decompression, encoding, etc</span></p><p class="c1"><span class="c0">Workers make sense for heavy work, but have a cost: startup, IPC, etc</span></p><p class="c1"><span class="c0">Benefits have to justify the cost, and in some cases we found that it’s not worth it: state management, rendering</span></p><p class="c1"><span>So there’s a clear perf win for </span><span>heavy work </span><span class="c0">&nbsp;cases.</span></p><p class="c1"><span class="c0">postMessage is not ergonomic so proxying that work to a worker is nicer to work with, but then we hit surprise thread hops that introduce latency and memory overhead. And not APIs really work.</span></p><p class="c1"><span class="c0">Scheduling based approach may do better, inspired by iOS Grand Central Dispatch.</span></p><p class="c1"><span class="c0">Seems to work well for developers, and the system maintains control over thread management.</span></p><p class="c1"><span class="c0">Encourages devs to structure their code in a way that works for background threads</span></p><p class="c1"><span>Prototyped a worker task queue API, and looked at problems: thread hops add latency (mostly android, but also ios), structured cloning is also expensive. Android has async task API which is not great so trying to avoid </span><span>posting</span><span class="c0">&nbsp;results back to main thread.</span></p><p class="c1"><span class="c0">Want to avoid posting tasks on same thread by default</span></p><p class="c1"><span class="c0">Need to avoid making the main thread a single point of slowness.</span></p><p class="c1"><span class="c0">Task Worklets</span></p><p class="c1"><span class="c0">It’s a simpler task queue API. Worklet has advantage vs. a worker: more restricted surface, has a registry pattern, etc.</span></p><p class="c1"><span class="c0">&lt;displays API&gt;</span></p><p class="c1"><span class="c0">The main thread registers a task, and lazily gets results (by awaiting on them)</span></p><p class="c1"><span class="c0">When posting tasks to a queue, the results of one task are the input to the following task, so chaining the data rather than moving everything through the main thread.</span></p><p class="c1"><span class="c0">The system can be smart enough to run these tasks in parallel.</span></p><p class="c1"><span class="c0">Advantages of this are being able to pass the task as a pointer, almost like a representations of what the results would be. Assignment of tasks to thread can happen intelligently, avoiding the problems of moving everything through the main thread. Workers can coordinate data between themselves.</span></p><p class="c1"><span class="c0">No explainer up yet, but WIP. Wanted to know what folks think.</span></p><p class="c1"><span class="c0"><b>Ben</b>: Workers are heavy because of implementation decisions, but could be lighter. The spec doesn’t require it. They don’t have to map to a single thread. </span></p><p class="c1"><span class="c0"><b>Shubhie</b>: we can incrementally improve workers</span></p><p class="c1"><span><b>Todd</b>: We used to have workers that didn’t map to threads, but found interop issues and changed the implementation. </span></p><p class="c1"><span class="c0">Similar to the C# task model. Syntactic sugar can be better. Is there a way to force block?</span></p><p class="c1"><span><b>Shubhie</b>: The “</span><span>await </span><span class="c0">.result()” is blocking</span></p><p class="c1"><span class="c0"><b>Todd</b>: So while blocking on the result, the main thread could be one of the processing threads</span></p><p class="c1"><span class="c0"><b>Benoit</b>: You example is really simple, could have done that as a subtask inside the worklet. What’s the value of the mechanism?</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: The value is enabling the main thread to schedule that work. The main thread can decide what work happens and when, but the workers can coordinate to do that most efficiently.</span></p><p class="c1"><span class="c0"><b>Benoit</b>: So that syntax makes it easier to chain?</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: Yeah, otherwise you can do that today but messaging between the worker and the main thread is awkward.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Composable worker heavy workloads is pretty cool.</span></p><p class="c1"><span class="c0"><b>Ben</b>: Is this pollyfillable today? Can message passing implement this? Is there a core primitive missing?</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: we tried to implement a polyfill. Hard to implement the worklet-y parts but did that with a worker. Wasn’t as efficient. Reduced the thread hops a bit, but in C++ we can avoid the main thread entirely</span></p><p class="c1"><span class="c0"><b>Ben</b>: Channel and message ports can do the same between threads</span></p><p class="c1"><span class="c0"><b>Tim</b>: You can’t use your knowledge of available resources to decide how many threads</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: Dunno how good the JS implementation could be, but native impl would be better.</span></p><p class="c1"><span class="c0"><b>Ben</b>: If Edge moved to strict 1:1 threading, that may not work, but maybe the browser can reuse threads</span></p><p class="c1"><span class="c0"><b>Todd</b>: Maybe you’re arguing for a native thread pool primitive.</span></p><p class="c1"><span class="c0"><b>Ben</b>: A short worker is currently very slow in some implementations, but we could provide a thread pool and make it faster. The spec allows for it, and Firefox ship something like that.</span></p><p class="c1"><span class="c0">Doesn’t save time to create globals, but can help. The syntactic sugar can help.</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: There are libraries that are solving similar things. No huge uptake, but a polyfill version of this may be better.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Can you define thread-hop?</span></p><p class="c1"><span><b>Shubhie</b>: Serialization, queing</span><span>, hopping over to worker</span><span>, and </span><span>de</span><span class="c0">serialization back. Some previous attempts created more hops. This one reduces them, by not coordinating through the main thread.</span></p><p class="c1"><span><b>Markus</b>: API is really neat. Declaring everything up front may not be enough, as logic of task running may vary based on the results. Also, does that support multiple tasks input</span><span>t</span><span class="c0">ing to a single task or just linear chains.</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: Yeah, it does. We have a test that shows these cases</span></p><p class="c1"><span><b>Benoit</b>: Does the work getting posted immediately to a worklet or does it wait on the microta</span><span>s</span><span class="c0">ks queue?</span></p><p class="c1"><span class="c0"><b>Shubhie</b>: it gets posted immediately</span></p><p class="c1"><span class="c0"><b>Todd</b>: Folks seem interested. Number of cases that need to be proven is significant. We can sync offline.</span></p><p class="c1 c3"><span class="c0"></span></p><h2 class="c6" id="h.se3632b9q5z"><span class="c19">JS self profiling</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/vdjeric/js-self-profiling&amp;sa=D&amp;source=editors&amp;ust=1613252918990000&amp;usg=AOvVaw1USDQ-aFZeGjN_7uLyHQqq">proposal</a></span><span>/</span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://github.com/vdjeric/js-self-profiling/blob/master/doc/tpac-2018-slides.pdf&amp;sa=D&amp;source=editors&amp;ust=1613252918990000&amp;usg=AOvVaw2DphoyCL-F6rplq0DInabM">slides</a></span></p><p class="c1"><span class="c0"><b>Andrew</b>: sampling profiler for JS, that produces a trace.</span></p><p class="c1"><span class="c0">Can be processed by client-side JS or sent to a server for aggregation.</span></p><p class="c1"><span class="c0">Why do we want this?</span></p><p class="c1"><span class="c0">In production, execution varies and to get a profile of user traces is painful. Having a native profiler would prevent the need to introduce instrumented code.</span></p><p class="c1"><span>Serving the in</span><span>s</span><span class="c0">trumentation only in certain cases break caches, and native profiler doesn’t.</span></p><p class="c1"><span class="c0"><b>Use cases</b>: complex web apps and analytics</span></p><p class="c1"><span class="c0">Want to give UAs a lot of freedom in how they implement this</span></p><p class="c1"><span class="c0">Want to create a structurally compressed format</span></p><p class="c1"><span class="c0">Logical profiler - can spin up multiple per browsing context</span></p><p class="c1"><span class="c0"><b>Tim</b>: If the sample interval is configurable, multiple profilers can end up sampling a lot!</span></p><p class="c1"><span class="c0"><b>Andrew</b>: was thinking of common denominator</span></p><p class="c1"><span class="c0">For trace format we used one that’s similar to the chrome tracing format, which is trie </span></p><p class="c1"><span class="c0">It’s ordered by times</span></p><p class="c1"><span class="c0"><b>Privacy and security</b>: dealing with third party frames needs to be careful. Should not expose more data than performance.now exposes, but fuzzing may be appropriate.</span></p><p class="c1"><span class="c0">We want to see stack frames cross-origin</span></p><p class="c1"><span>Implemented something similar on facebook.com, using a web worker. In</span><span>s</span><span class="c0">trumenting the JS and sends the info through a shared array buffer.</span></p><p class="c1"><span class="c0">Hope a native implementation would be significantly faster.</span></p><p class="c1"><span class="c0"><b>Alex Russell</b>: What do you mean by fuzzing?</span></p><p class="c1"><span class="c0"><b>Andrew</b>: Sample times will have to be fuzzed</span></p><p class="c1"><span class="c0">This will also include 3P JS frames running in the top level.</span></p><p class="c1"><span class="c0"><b>Chris</b>: By 3P you mean a script on same document that came from a different origin</span></p><p class="c1"><span class="c0"><b>Andrew</b>: Yeah, in the past we ran into security issues with those</span></p><p class="c1"><span class="c0">So we propose to enable that for CORS enabled JS fetches, or with a Profiling-Allow-Origin header</span></p><p class="c1"><span class="c0"><b>Alex Russell</b>: What’s the motivation? Is there any information that’s not owned by the origin? If you invited 3P script, it has no right to privacy? We want to protect the 3P source, but not necessarily its run times</span></p><p class="c1"><span class="c0"><b>Andrew</b>: This will leak function names, which may contain sensitive data, if script evals</span></p><p class="c1"><span class="c0"><b>Tim</b>: So if you evaled user/password, that would be bad</span></p><p class="c1"><span class="c0"><b>Andrew</b>: In that case, what do we do with 3P scripts that didn’t opt-in? Fuzz with “unknown” category.</span></p><p class="c1"><span class="c0">Want the spec to be implementable, so want to give UA leeway on how to implement and instrument.</span></p><p class="c1"><span class="c0">Need control over sampling rate, also concerns around providing new timers.</span></p><p class="c1"><span class="c0">UA decides on supported sample rates and takes best-effort approach.</span></p><p class="c1"><span class="c0">VMs should have the ability to inline or optimize away frames (JS stack frames).</span></p><p class="c1"><span>s</span><span class="c0">tart/stop should be async</span></p><p class="c1"><span class="c0">Open questions:</span></p><p class="c1"><span class="c0">If non-cors 3P calls 1P script, should we include them? It’s already exposed in the platform, not including them may make traces difficult.</span></p><p class="c1"><span class="c0"><b>Buffering</b>: proposed sample count, but wondering if that is enough. Should we constrain on bytes/frames?</span></p><p class="c1"><span class="c0"><b>Tim</b>: For UT, people can put arbitrary data, so same concern. Sample count seems to be enough.</span></p><p class="c1"><span class="c0"><b>Chris</b>: How hard would it be to process on the client side?</span></p><p class="c1"><span class="c0"><b>Andrew</b>: Main use case is server side. Client side use-case is for dev tools like thing.</span></p><p class="c1"><span class="c0"><b>Chris</b>: If we keep it compressed on the client, it would save memory and can send it compressed</span></p><p class="c1"><span class="c0"><b>Alex</b>: Would be better to have an optimized representation of the data</span></p><p class="c1"><span class="c0"><b>Chris</b>: If no real use-case, that would be better, and extensions can do fancier things</span></p><p class="c1"><span class="c0"><b>Tim</b>: Reporting API lets you specify a server to send it to. Could use something similar</span></p><p class="c1"><span class="c0"><b>Chris</b>: Would be good for low-end devices</span></p><p class="c1"><span class="c0"><b>Andrew</b>: Is there interest in other categories? Currently only defining JS, but maybe Layout is interesting</span></p><p class="c1"><span class="c0"><b>Tim</b>: probably want to punt it. Also maybe you want to profile only long tasks to save on data</span></p><p class="c1"><span class="c0"><b>Chris</b>: Would be interesting to have the function names there</span></p><p class="c1"><span class="c0"><b>Npm</b>: How do you see the gaps when no JS ran</span></p><p class="c1"><span class="c0"><b>Benoit</b>: You just know that you weren’t executing JS, but don’t know why.</span></p><p class="c1"><span class="c0"><b>Andrew</b>: Browser could be working or could be idle</span></p><p class="c1"><span class="c0"><b>Benoit</b>: Accounting for that would add more information, but would be more complex</span></p><p class="c1"><span class="c0"><b>Tim</b>: Maybe add a “browser was doing something” category</span></p><p class="c1"><span class="c0"><b>Chris</b>: That would be extremely valuable, as devs can take the traces and file bugs</span></p><p class="c1"><span class="c0"><b>Andrew</b>: categories show up in frames, so one stack can have different categories</span></p><p class="c1"><span class="c0"><b>Tim</b>: I don’t think we’d be exposing fined-grained categories in the next 5-10 years, so maybe not expose in registration</span></p><p class="c1"><span class="c0"><b>Andrew</b>: and 3P JS as an “unknown” category</span></p><p class="c1"><span class="c0"><b>Andrew</b>: considered interest in marker support. A bit redundant with User Timing.</span></p><p class="c1"><span class="c0"><b>Todd</b>: Samples have timestamps based on the timeorigin, so can be sorted out later</span></p><p class="c1"><span class="c0"><b>Andrew</b>: Last open question regarding format. Worth standardizing? </span></p><p class="c1"><span class="c0"><b>Tim</b>: I think we should</span></p><p class="c1"><span class="c0"><b>Andrew</b>: Questions?</span></p><p class="c1"><span class="c0"><b>Todd</b>: Is there an entry point to differentiation set timeouts from event callbacks? If the implementation could, would that be useful?</span></p><p class="c1"><span class="c0"><b>Andrew</b>: definitely worth considering</span></p><p class="c1"><span class="c0"><b>Markus</b>: Just implemented that in the Gecko profiler</span></p><p class="c1"><span class="c0"><b>Tim</b>: V8 wants to see examples of other customers, a more precise specification, and to verify that the performance won’t be too bad</span></p><p class="c1"><span><b>Alex C</b>: Similar question, how much o</span><span>verh</span><span class="c0">ead does the polyfill have?</span></p><p class="c1"><span class="c0"><b>Andrew</b>: Got 5% degradation in Chrome, but was a little bit biased</span></p><p class="c1"><span class="c0"><b>Alex C</b>: So with this enabled, everything is ~5% slower?</span></p><p class="c1"><span class="c0"><b>Andrew</b>: May be closer to the devtools profiler</span></p><p class="c1"><span class="c0"><b>Tim</b>: Not really, as devtools use a separate thread, which we can’t do here. This will be slower</span></p><p class="c1"><span class="c0"><b>Alex C</b>: Ideally a native implementation would be faster, but still slower than not profiling. This will hurt the performance of the profiled users, but will help improving it for everyone else.</span></p><p class="c1"><span class="c0">Would the users be able to opt-out? Can the UA have a minimum sampling rate?</span></p><p class="c1"><span class="c0"><b>Eric Faust</b>: Talking about adding client code. Would that make other contexts slower? Because facebook has the right to make itself slower</span></p><p class="c1"><span class="c0"><b>Andrew</b>: UAs can avoid spin up a profiler</span></p><p class="c1"><span class="c0">&nbsp;</span></p><p class="c1 c3"><span class="c0"></span></p><h2 class="c6" id="h.vs0138jsj80"><span class="c19">Page prerendering</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1p9rAYi4z4OscjD6Cjx-2KE-Z97IMKq4WTGTCW9fMAYc/edit?usp%3Dsharing&amp;sa=D&amp;source=editors&amp;ust=1613252918995000&amp;usg=AOvVaw0DkBpi4nQHdBq2HW4V635s">slides</a></span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Qingqian</span><span class="c0"><b></b>: Use case for baidu: 60% of users select the first result in the search page.</span></p><p class="c1"><span class="c0">If we prerender that result, the UX to visit that page is seamless. It’s a big win.</span></p><p class="c1"><span class="c0">Time to render page is reduced by 60% if we prerender.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">Less browsers support prerendering because it’s misused frequently.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Limitations of prerendering</b>: browser decides whether or not the page should be prerendered.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">We experimented with prerendering using workarounds (iframe and MIP).</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">We need browser vendors to make some prerendering more tractable (?)</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>What we want</b>: a policy for the page which will be prerendered. We want to reduce the unnecessary render by:</span></p><ul class="c12 lst-kix_60d2jr3xce8v-0 start"><li class="c1 c4 li-bullet-0"><span class="c0">Only prerendering the first screen DOM</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Only loading the first screen image</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Not executing the async script that just loaded it.</span></li></ul><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>The question</b>: should we use Feature Policy?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: have you looked at alternative ways to get the resources in? (prefetch navigation, preload subresources without prerendering)</span></p><p class="c1"><span class="c0">What is the performance difference that you see?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Qingqian</span><span class="c0"><b></b>: It’s a UX thing (?). It’s a specification in the web performance working group. There is not a good use case for prerendering currently.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: Have you looked at upcoming standards that support that use case (portals)?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Qingqian</span><span class="c0"><b></b>: Can resolve part of the problem. Some pages may do many heavy tasks when being prerendered. We want to be able to run these.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: You mentioned feature policy being useful here, are you suggesting we use feature policy here for things that are being prerendered?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Qingqian:</span><span class="c0">&nbsp;I’m unsure whether or not we can add a feature-policy to be used in prerender.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: We discussed a size policy, where you could only download so many bytes (most applicable). Consider no-script policy? Do you have ideas of other feature policies? They’re likely to be useful for other contexts.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Qingqian</span><span class="c0"><b></b>: I need more suggestions.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: no one size fit all solution here, want a different set of feature policies? I don’t have enough context on feature policies in general to use it for this use case</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: not sure as well. If you’ve looked at signed exchanges and portals, what’s the gap from your perspective</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Qingqian</span><span class="c0"><b></b>: the page in portals (?) is now AMP page, before google used portals to prerender pages. Now, google uses iframe to prerender AMP pages. AMP pages have problems with prerendering. In prerender, must be drawn in the web components runtime. If the page is not an AMP page, the page prerender may not run.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: Understand use case, Google people not in room. Feel free to reach out.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: the piece that is missing is that there’s no way to restrict the page to run outside of iframes, which is what AMP validation enables</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Qingqian</span><span class="c0"><b></b>: maybe we can provide more details, more use cases, to explain what the limitations are and what we need for next time. Will write explainer on GitHub.</span></p><p class="c1 c3"><span class="c0"></span></p><h2 class="c6" id="h.st6gxjsidq6p"><span class="c19">Priority hints</span></h2><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: Have made progress on the spec, chromium implementation, built for synthetic sites trying to emulate loading patterns. Haven’t reached any conclusions with those experiments.</span></p><p class="c1"><span class="c0">H2 server prioritization is hard, the next step is to run similar experiments with (???) as server side transport stack so we exclude impact of H2 prioritization diluting benefits</span></p><p class="c1"><span class="c0">Otherwise, work being done on more experiments. Still WIP, no conclusive evidence yet.</span></p><p class="c1"><span class="c0">Interested in exploring origin trials. Replace with native.</span></p><p class="c1 c3"><span class="c0"></span></p><h2 class="c6" id="h.m4cyh42odqu"><span class="c19">Page lifecycle</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1lqWh6rEnC0IqPq0yh7enAvW1LumxjhMdJO9reVI0-28/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252918999000&amp;usg=AOvVaw0jgjrX1fPaUUeKumoglOjk">slides</a></span></p><p class="c1"><span class="c5">Philip</span><span class="c0"><b></b>: API shipped in chrome 68. Some features not shipped yet, TBD. IndexedDB in progress. Missing client ID. Could use client ID to restore data for specific page. Work not started yet.</span></p><p class="c1"><span>Since shipping, freezing tabs on desktop/android. </span><span>Discarding (only) o</span><span class="c0">n hold due to user complaints.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">Shipped freezing loading in M67 (1-3% data saving), freezing non-timers in M68 (72% renderer CPU saving (battery) in background)</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">Work on bf-cache started as well. Bf-cache similar to frozen state, discussion regarding consolidation.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Perf wins</b>: renderer memory reduction of -3.3% at 50th percentile, -3% at 75th percentile. CPU reduction of -16% main thread, -40% dedicated worker.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Nate</span><span class="c0"><b></b>: timeline on future work? For all lifecycle stuff.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Philip</span><span class="c0"><b></b>: API work and intervention work. We’re trying to work out issues for desktop discarding. We’re seeing obvious user benefits from this, make sure we do it right.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: instead of discarding serializing to disk, other options?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: considering it.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Todd</span><span class="c0"><b></b>: edge does this, depends on OS infra.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Benoit</span><span class="c0"><b></b>: concerned about user backgrounding on the suspend case.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: lots of heuristics detecting and excluding this. Heuristics not perfect, can incentivize doing horrible things. Need better ones, is hard</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Philip</span><span class="c0"><b></b>: looking at APIs to make that possible</span></p><a id="id.ry6dt3obdydc"></a><h2 class="c6" id="h.m9k0hte7bmri"><span class="c19">Element timing</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1lyzjzzQVw6iY9kAiAxNCDVuwF6Ralo2iOS0D6LlgH2Y/edit%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252919001000&amp;usg=AOvVaw1kGrw15wwdIisWwDVd1rEY">slides</a></span><span>/</span><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/document/d/1blFeMVdqxB0V3BAJh60ptOBFY7cJSXnf7VyW3wspbZ8/edit%23heading%3Dh.eny79fwwx642&amp;sa=D&amp;source=editors&amp;ust=1613252919002000&amp;usg=AOvVaw0sgDRAQsetIXAKeJmeH89P">explainer</a></span></p><p class="c1"><span class="c5">Npm</span><span><b></b>: </span><span class="c0"><b>motivation</b>: measure time that elements are rendered on the screen. We decided for reasons of complexity to restrict this to &lt;img&gt; tags for now. Plan to expand this to text and other elements in the future.</span></p><p class="c1"><span class="c0">Benefits:</span></p><ul class="c12 lst-kix_4a8urx38ygu2-0 start"><li class="c1 c4 li-bullet-0"><span class="c0">Allow web devs to measure the first time that &lt;img&gt; elements show up to the screen</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Allows analytics providers to measure the first rendering times of key elements</span></li></ul><p class="c1"><span class="c0">What img elements do we care about?</span></p><ul class="c12 lst-kix_cfaanro8u333-0 start"><li class="c1 c4 li-bullet-0"><span class="c0">User-registered elements</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Elements that take a large percentage of the viewport (exact value tbd, starting at 15% of viewport). Automatically registered for observation. Enables analytics providers to provide some info</span></li></ul><p class="c1"><span class="c0">What about visibility/cross-origin?</span></p><ul class="c12 lst-kix_nr9u9ak7u2vs-0 start"><li class="c1 c4 li-bullet-0"><span class="c0">Entry creation cannot be strictly based on visibility</span></li></ul><ul class="c12 lst-kix_nr9u9ak7u2vs-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">If the element is there but hidden by a pop-up, or the visibility is set to none</span></li></ul><ul class="c12 lst-kix_nr9u9ak7u2vs-0"><li class="c1 c4 li-bullet-0"><span class="c0">Only entries corresponding to a CORS-same-origin response are exposed</span></li></ul><p class="c1"><span class="c0">What do we want to expose?</span></p><ul class="c12 lst-kix_o0y39f1jde3c-0 start"><li class="c1 c4 li-bullet-0"><span class="c0">The rendering timestamp of the image</span></li></ul><ul class="c12 lst-kix_o0y39f1jde3c-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">Post-decode, available</span></li></ul><ul class="c12 lst-kix_kolajlgg2iz3-0 start"><li class="c1 c4 li-bullet-0"><span class="c0">The intersection rect between image and viewport</span></li></ul><ul class="c12 lst-kix_kolajlgg2iz3-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">Computed at the same time as rendering timestamp of image</span></li></ul><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: for progressive images, image is fully downloaded and fully decoded, yes?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Npm</span><span class="c0"><b></b>: yes. Will need to dig into html spec.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Gilles</span><span class="c0"><b></b>: based on flush, or when the person actually sees it?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Npm</span><span class="c0"><b></b>: first time that it renders post decode and load. I don’t know how to fix this problem, hoping it’s a rare case</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Gilles</span><span class="c0"><b></b>: not rare when page is constructed during initial path, often browser will flush a whole lot of content at once. What if browser is blocked, has to wait?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Npm</span><span class="c0"><b></b>: something must be rendered for it to be computed.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">Simplest use case is to measure the time that images are displayed on navigation.</span></p><p class="c1"><span class="c0"><b>Alternate use case</b>: compute delta between user input that leads to &lt;img&gt; loading with the rendering timestamp.</span></p><p class="c1"><span class="c0">The intersectionRect helps knowing how much of the image was visible during its first paint.</span></p><p class="c1"><span class="c0">Useful beyond just pageload, even though it’s not obvious</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0"><b>Re</b>: IDL: name will be timing value, or ID, or “img” (generic image string). May not be enough to determine what the image is.</span></p><p class="c1"><span class="c0">We propose also exposing the source of the image. entryType is “element”. Has 0 duration, startTime is rendering timestamp. intersectionRect between image and viewport at the time the first paint occurs.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: for resource timing the name is URL? We should make consistent. Maybe if there’s no element timing/ID, we add separate attributes?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: gets messy for elements that are not images. Source is not populated in those cases. I guess you could have an image that’s an encoded blob.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: you still have a URL, don’t want to stuff into a performance entry. Let’s balance consistency with other performance APIs.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Npm</span><span class="c0"><b></b>: equivalent from resource timing would be name. Would we still want the attribute value?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: include other DOMStrings if present.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: let’s bikeshed that offline</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Qingqian</span><span class="c0"><b></b>: once the main image resource, not sure it will be rendered in the browser. I think it is timing of the image animate.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: should we tie this to the resource timing attribute?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Qingqian</span><span class="c0"><b></b>: not sure it’s related. Can add other attribute to show the image resource has been fetched.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: yep, related to consolidation discussion.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: nit: comment here says first paint.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Npm</span><span class="c0"><b></b>: yep it’s wrong</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: it’s possible it’s painted before that, we should be careful there.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Npm</span><span class="c0"><b></b>: should we detect these cases?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: either the last paint before it’s available, or the first paint after?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: let’s think about this some more.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Markus</span><span class="c0"><b></b>: seems reasonable enough</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Nate</span><span class="c0"><b></b>: the way we embed images, we’ll end up showing a sprited div background. Would be nice if future versions of the spec that could support this.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Npm</span><span class="c0"><b></b>: yes, let’s expand this to other types of elements once we can figure out to measure.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: seems easy to include background images that are &gt; 15% of viewport</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: for sprites we need to calculate the display size of the sprite particles?<br></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: intrinsic size of the image, or the display size. Whichever is smaller. Don’t have a background size case yet.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Todd</span><span class="c0"><b></b>: for us, depends on implementation, adoption, having a web site say they could measure more accurately</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Nate</span><span class="c0"><b></b>: if we the sprite thing, it would be super valuable.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: origin trial the best way to get feedback?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Todd</span><span class="c0"><b></b>: we might get some things slightly wrong, it’d be great to get interest first</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Benoit</span><span class="c0"><b></b>: gaming can introduce multimodality</span></p><p class="c1 c3"><span class="c0"></span></p><a id="id.nqwus216bv5z"></a><h2 class="c6" id="h.xywq2mlyhhef"><span class="c19">Layout stability</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1FSpgaQobGOHKCHYdGSn2xK2vpiG-Ynw6Yvjhv4abtIU/edit?ts%3D5bc609d1%23slide%3Did.g445f3ec104_0_69&amp;sa=D&amp;source=editors&amp;ust=1613252919008000&amp;usg=AOvVaw0EhH8Ls6ZQiZ1boJiVPQKx">slides</a></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: layout instability can be summed up as stuff jumping around when page is loading.</span></p><p class="c1"><span class="c0">Stuff getting pushed around by ads, etc.</span></p><p class="c1"><span class="c0">Irritating for users. They want this problem gone.</span></p><p class="c1"><span class="c0">Let’s surface via analytics provider to move the ecosystem.</span></p><p class="c1"><span class="c0">We want to quantify instability in layout. Initial implementation ready, shows percentage of “layout unstable”.</span></p><p class="c1"><span class="c0">What causes layout instability?</span></p><ul class="c12 lst-kix_hj1iazp81ndn-0 start"><li class="c1 c4 li-bullet-0"><span class="c0">Ads</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Unsized images</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Web fonts</span></li></ul><ul class="c12 lst-kix_hj1iazp81ndn-1 start"><li class="c1 c2 li-bullet-0"><span class="c0">Async load</span></li></ul><ul class="c12 lst-kix_hj1iazp81ndn-0"><li class="c1 c4 li-bullet-0"><span class="c0">Scrollbars</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Animations</span></li></ul><p class="c1"><span class="c0">How to compute?</span></p><ul class="c12 lst-kix_ceulq9qdp9ut-0 start"><li class="c1 c4 li-bullet-0"><span class="c0">For each element whose origin changed, we take the union rect of old and new rect</span></li><li class="c1 c4 li-bullet-0"><span class="c0">Report the fraction of viewport that is covered by this union.</span></li></ul><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Benoit</span><span class="c0"><b></b>: do you double-count based on DOM structure?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: no, it’s a set union, can’t double count.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Markus</span><span class="c0"><b></b>: shifting by one pixel is the same as 200px regarding fixed cost? Yes.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: element’s origin is its border box. Same with region, it’s the union of all of its box fragments.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">Consider element that occupies 50% of viewport. It moves by a distance equal to have of its height. The layout instability metric is 75%. Caps out at 1 (100%).</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">It’s possible to get a score of zero on this metric.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">To prevent animations from showing up as layout instability we check to see if the origin moved more than 3 css pixels. May want to parameterize this.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Benoit</span><span class="c0"><b></b>: can see how it’s practical.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: have implementation in chrome. Similar to what’s described. When keeping track of union of boxes, we can’t do this in a way that’s perfect and adequately performant. We quantize this to a grid to reduce the complexity of the region. Lets us get good performance, pretty good quality. Worth allowing some amount of ambiguity?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Philip</span><span class="c0"><b></b>: what about elements added/removed to the page?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: they’re fine, as long as they don’t move other stuff around</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">Expose this as performance entry with fractional jank. Maybe a little crazy to surface per frame, spammy. Want to do coalescing.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">How long do you wait?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">Cap on jank. If &gt;4, page is already terrible. May be sane.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: as a browser, would report on register. What about analytics providers?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: let’s put more thought into that. Graph displayed is on mobile.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Alex</span><span class="c0"><b></b>: CSS is loaded a second after rest of content. How to penalize?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: we should catch this.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Markus</span><span class="c0"><b></b>: container box that is short, absolutely positioned element at the bottom edge. As content grows, absolute box moves. Should catch?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: yep, we should.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Alex</span><span class="c0"><b></b>: how expensive is this to compute compared to the layout itself?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: initially, terrible. Implemented quantization of regions, we can’t see any latency increase inside the noise. Embeds nicely into our layout architecture, would be nice to know if it was performant in other architectures.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">Is this reasonable? Is this the right place to pursue this</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Alex</span><span class="c0"><b></b>: seems very useful for developer tools. We could be motivated by a success story of a web site that improved via this.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: makes sense. We should do that.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Gilles</span><span class="c0"><b></b>: would be great to catch regressions with. Fundraising banners, etc</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Benoit</span><span class="c0"><b></b>: would be very useful for FB. we care about this, useful measure to track</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: either we record it all the time, or we require header observation. Don’t support header registration yet, part of that depends on the performance overhead.</span></p><p class="c1"><span class="c0">Does anyone have thoughts on ambiguity in spec to make this performant?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Markus</span><span class="c0"><b></b>: as long as it’s well-specified, won’t be a problem. Good question whether to recommend a particular optimization.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Benoit</span><span class="c0"><b></b>: intuitively, cannot prove</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Npm</span><span class="c0"><b></b>: in practice, might work</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Benoit</span><span class="c0"><b></b>: maybe have an error bound? Not sure.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Philip</span><span class="c0"><b></b>: can we exclude animations for all? Css animations, transitions, etc?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: can’t capture one-frame animations that might game things. Do we actually care about this metric being gamed? If we try and make exceptions for animations, we might start missing legitimate jank</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Philip</span><span class="c0"><b></b>: was thinking that most animations were on compositable properties. Not the case.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: we’ll come back with a crisper proposal at some point. Maybe better name. Change to layout instability from jank.</span></p><h2 class="c6" id="h.rjbkw8ocj9we"><span class="c19">Platform supported A/B testing</span></h2><p class="c1"><span class="c9"><a class="c8" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1TIiTg1FudyFlIhi7YHmR_GpHyroyqHHRm-qXSY3IBLA/edit?ts%3D5bc85659%23slide%3Did.p&amp;sa=D&amp;source=editors&amp;ust=1613252919014000&amp;usg=AOvVaw22ovcY3dIe-NxnaMAPosth">slides</a></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: want to find out if this working group is the right place for the proposal.</span></p><p class="c1"><span class="c0"><b>Problem</b>: RUM analytics A/B testing. Currently done using cookies, solved problem, tricky when you end up with multiple analytics packages on page. Having the browser provide support for analytics providers to coordinate provides lots of value.</span></p><p class="c1"><span class="c0">Primary reason of interest is to provide privacy sensitive metrics. Chrome user experience report cares about these. Want to be able to get information about experiments without leaking data in traces. Having improved performance.memory and improved network usage metrics provides some value, but is not actionable. To make this actionable, we need to enable A/B testing integrated with the browser. Lets us aggregate effectively.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">Want a privacy/security sensitive way of managing experiment groups. Proposal: have a browser send an experiment seed, page responds with a group count and a sticky flag. Let’s stop and see how appropriate this is for this working group.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: with crux, this will support multiple equally sized groups. We cannot run experiments on a small number of users.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: RUM analytics will be able to use same experiment ID.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Todd</span><span class="c0"><b></b>: If there are websites that want to use a standardized mechanism for experiments, it fits in the web perf wg because it involves gathering and reporting data</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: a good use case, but don’t think the WG should prioritize for that reason</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: explore the other use case, see if it’s more generic and can have a better fit</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Todd</span><span class="c0"><b></b>: ask to web sites if they want a standard way</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: in order to preserve privacy in the aggregate case, we need to make the API clumsier.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Todd</span><span class="c0"><b></b>: would other vendors say no due to this?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: high interest in memory data from gsuite</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Nate</span><span class="c0"><b></b>: would be excited about this. Would be nice if other sites couldn’t figure out which experiments are running.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: block data exposed, not experiment?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Nate</span><span class="c0"><b></b>: yep</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: interest in other browser vendors similar to crux?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Markus</span><span class="c0"><b></b>: not what we do at FF</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Alex</span><span class="c0"><b></b>: seems chrome-specific, shouldn’t be standardized right now</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: value for non-crux usage is the initial seed that A/B testers don’t have. Not everyone has access to set-cookie</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: in this proposal, the browser comes up with the seed. Scope of seed is the same as scope of the cookie. What’s the win over cookies?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: not everyone wants to set cookies on a site</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: could avoid namespace collision. Maybe an argument for browsers to support analytics collaboration.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Alex</span><span class="c0"><b></b>: right now, not too compelling</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Benoit</span><span class="c0"><b></b>: don’t you want independent experiment groups?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: analytics wants to split up based on experiment groups.</span></p><p class="c1"><span class="c0">Again, is this not a good venue for this discussion?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Markus</span><span class="c0"><b></b>: not sure, anything that browsers ask is going to be part of the platform, in which case needs to be standardized. May not need to be now</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Yoav</span><span class="c0"><b></b>: if this will change in the future, won’t break content in the future. Existing content could be transitioned.</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c0">What if we don’t send a seed?</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Tim</span><span class="c0"><b></b>: how to avoid this happening? Let’s have this discussion in wicg</span></p><p class="c1 c3"><span class="c0"></span></p><p class="c1"><span class="c5">Alex</span><span><b></b>: is seed new tracking vector? Not yet interested in implementing it.</span></p></div></div><div id="footer"><span>Published by <a target="_blank" title="Learn more about Google Drive" href="https://docs.google.com/">Google Drive</a></span><span class="dash">–</span><a href="https://docs.google.com/u/0/abuse?id=AKkXjowixbJ6cr9y0op04R0FubMgveE1uYlyWJabNAtUx5O1acqO3KYeF39ApmTMvXOf1ZFTfa081bx0hOeblw0:0">Report Abuse</a></div><script type="text/javascript" nonce="">(function(){/*

 Copyright The Closure Library Authors.
 SPDX-License-Identifier: Apache-2.0
*/
var aa="function"==typeof Object.defineProperties?Object.defineProperty:function(a,b,c){if(a==Array.prototype||a==Object.prototype)return a;a[b]=c.value;return a};function ba(a){a=["object"==typeof globalThis&&globalThis,a,"object"==typeof window&&window,"object"==typeof self&&self,"object"==typeof global&&global];for(var b=0;b<a.length;++b){var c=a[b];if(c&&c.Math==Math)return c}throw Error("Cannot find global object");}var ca=ba(this);
function da(a,b){if(b)a:{var c=ca;a=a.split(".");for(var d=0;d<a.length-1;d++){var e=a[d];if(!(e in c))break a;c=c[e]}a=a[a.length-1];d=c[a];b=b(d);b!=d&&null!=b&&aa(c,a,{configurable:!0,writable:!0,value:b})}}var ea="function"==typeof Object.create?Object.create:function(a){function b(){}b.prototype=a;return new b},fa;
if("function"==typeof Object.setPrototypeOf)fa=Object.setPrototypeOf;else{var ha;a:{var ia={a:!0},ja={};try{ja.__proto__=ia;ha=ja.a;break a}catch(a){}ha=!1}fa=ha?function(a,b){a.__proto__=b;if(a.__proto__!==b)throw new TypeError(a+" is not extensible");return a}:null}var ka=fa;
function h(a,b){a.prototype=ea(b.prototype);a.prototype.constructor=a;if(ka)ka(a,b);else for(var c in b)if("prototype"!=c)if(Object.defineProperties){var d=Object.getOwnPropertyDescriptor(b,c);d&&Object.defineProperty(a,c,d)}else a[c]=b[c];a.o=b.prototype}da("Object.is",function(a){return a?a:function(b,c){return b===c?0!==b||1/b===1/c:b!==b&&c!==c}});var l=this||self;function la(){}function ma(a){var b=typeof a;return"object"==b&&null!=a||"function"==b}
function na(a,b){var c=Array.prototype.slice.call(arguments,1);return function(){var d=c.slice();d.push.apply(d,arguments);return a.apply(this,d)}}function oa(a,b){function c(){}c.prototype=b.prototype;a.o=b.prototype;a.prototype=new c;a.prototype.constructor=a;a.B=function(d,e,f){for(var g=Array(arguments.length-2),k=2;k<arguments.length;k++)g[k-2]=arguments[k];return b.prototype[e].apply(d,g)}}function pa(a){return a};var qa=Array.prototype.indexOf?function(a,b){return Array.prototype.indexOf.call(a,b,void 0)}:function(a,b){if("string"===typeof a)return"string"!==typeof b||1!=b.length?-1:a.indexOf(b,0);for(var c=0;c<a.length;c++)if(c in a&&a[c]===b)return c;return-1};function ra(a,b,c){for(var d in a)b.call(c,a[d],d,a)};var m;function p(a,b){this.i=a===sa&&b||"";this.j=ta}p.prototype.h=!0;p.prototype.g=function(){return this.i};var ta={},sa={};var ua=String.prototype.trim?function(a){return a.trim()}:function(a){return/^[\s\xa0]*([\s\S]*?)[\s\xa0]*$/.exec(a)[1]},va=/&/g,wa=/</g,xa=/>/g,ya=/"/g,za=/'/g,Aa=/\x00/g,Ba=/[\x00&<>"']/;function Ca(a,b){return a<b?-1:a>b?1:0};function q(a,b){this.i=b===r?a:""}q.prototype.h=!0;q.prototype.g=function(){return this.i.toString()};q.prototype.toString=function(){return this.i.toString()};function u(a){return a instanceof q&&a.constructor===q?a.i:"type_error:SafeUrl"}
var Da=/^(?:audio\/(?:3gpp2|3gpp|aac|L16|midi|mp3|mp4|mpeg|oga|ogg|opus|x-m4a|x-matroska|x-wav|wav|webm)|font\/\w+|image\/(?:bmp|gif|jpeg|jpg|png|tiff|webp|x-icon)|video\/(?:mpeg|mp4|ogg|webm|quicktime|x-matroska))(?:;\w+=(?:\w+|"[\w;,= ]+"))*$/i,Ea=/^data:(.*);base64,[a-z0-9+\/]+=*$/i,Fa=/^(?:(?:https?|mailto|ftp):|[^:/?#]*(?:[/?#]|$))/i;function Ga(a){if(a instanceof q)return a;a="object"==typeof a&&a.h?a.g():String(a);Fa.test(a)||(a="about:invalid#zClosurez");return new q(a,r)}
var r={},Ha=new q("about:invalid#zClosurez",r);var v;a:{var Ia=l.navigator;if(Ia){var Ja=Ia.userAgent;if(Ja){v=Ja;break a}}v=""}function w(a){return-1!=v.indexOf(a)};function x(a,b,c){this.i=c===Ka?a:""}x.prototype.h=!0;x.prototype.g=function(){return this.i.toString()};x.prototype.toString=function(){return this.i.toString()};var Ka={};function La(a,b,c,d){a=a instanceof q?a:Ga(a);b=b||l;c=c instanceof p?c instanceof p&&c.constructor===p&&c.j===ta?c.i:"type_error:Const":c||"";return void 0!==d?b.open(u(a),c,d,void 0):b.open(u(a),c)};function Ma(a){Ma[" "](a);return a}Ma[" "]=la;function y(a,b,c){return Object.prototype.hasOwnProperty.call(a,b)?a[b]:a[b]=c(b)};var Na=w("Opera"),z=w("Trident")||w("MSIE"),Oa=w("Edge"),Pa=Oa||z,Qa=w("Gecko")&&!(-1!=v.toLowerCase().indexOf("webkit")&&!w("Edge"))&&!(w("Trident")||w("MSIE"))&&!w("Edge"),Ra=-1!=v.toLowerCase().indexOf("webkit")&&!w("Edge"),Sa=w("Macintosh");function Ta(){var a=l.document;return a?a.documentMode:void 0}var Ua;
a:{var Va="",Wa=function(){var a=v;if(Qa)return/rv:([^\);]+)(\)|;)/.exec(a);if(Oa)return/Edge\/([\d\.]+)/.exec(a);if(z)return/\b(?:MSIE|rv)[: ]([^\);]+)(\)|;)/.exec(a);if(Ra)return/WebKit\/(\S+)/.exec(a);if(Na)return/(?:Version)[ \/]?(\S+)/.exec(a)}();Wa&&(Va=Wa?Wa[1]:"");if(z){var Xa=Ta();if(null!=Xa&&Xa>parseFloat(Va)){Ua=String(Xa);break a}}Ua=Va}var Ya=Ua,Za={},$a;if(l.document&&z){var ab=Ta();$a=ab?ab:parseInt(Ya,10)||void 0}else $a=void 0;var bb=$a;function cb(a){return y(a.prototype,"$$generatedClassName",function(){return"Class$obf_"+{valueOf:function(){return++db}}})}var db=1E3;function A(){}A.prototype.u=function(){return this.j||(Object.defineProperties(this,{j:{value:++eb,enumerable:!1}}),this.j)};A.prototype.toString=function(){var a=B(fb(gb(this.constructor)))+"@";var b=(this.u()>>>0).toString(16);return a+B(b)};function D(){}h(D,A);D.prototype.i=function(a){this.h=a;if(a instanceof Object)try{a.A=this}catch(b){}};function hb(a){a.h instanceof Error&&(Error.captureStackTrace?Error.captureStackTrace(a.h):a.h.stack=Error().stack)}D.prototype.toString=function(){var a=fb(gb(this.constructor)),b=this.l;return null==b?a:B(a)+": "+B(b)};function ib(){}h(ib,D);function jb(){}h(jb,ib);var eb=0;function E(){}h(E,jb);E.prototype.i=function(a){jb.prototype.i.call(this,Object.is(this.g,"__noinit__")?a:this.g)};function kb(){}h(kb,E);function lb(a,b){return"string"==typeof a?a.charCodeAt(b):a.g(b)};function B(a){return null==a?"null":a.toString()}function mb(a){return 65536<=a?B(String.fromCharCode((55296+((a-65536|0)>>10&1023)|0)&65535))+B(String.fromCharCode((56320+((a-65536|0)&1023)|0)&65535)):String.fromCharCode(a&65535)}function nb(a,b){var c=b,d=a.length,e;b=lb(a,(e=c,c=c+1|0,e));var f;if(e=55296<=b&&56319>=b&&c<d)a=f=lb(a,c),e=56320<=a&&57343>=a;var g;e?g=65536+((b&1023)<<10)+(f&1023)|0:g=b;return g};function ob(a,b){this.h=a;this.g=b}h(ob,A);function fb(a){var b=cb(a.h);0!=a.g&&(b="L"+B(b)+";");a=a.g;for(var c="",d=0;d<a;d=d+1|0)c=B(c)+"[";return B(c)+B(b)}ob.prototype.toString=function(){return"class "+B(fb(this))};function gb(a){var b=0;return y(a.prototype,"$$class/"+b,function(){return new ob(a,b)})};function pb(a,b){return null==a?a:b?decodeURI(a):decodeURIComponent(a)};var qb=/^(?:([^:/?#.]+):)?(?:\/\/(?:([^/?#]*)@)?([^/#?]*?)(?::([0-9]+))?(?=[/#?]|$))?([^?#]+)?(?:\?([^#]*))?(?:#([\S\s]*))?$/;function rb(a){a=qb.exec(a);for(var b=[],c=0;7>=c;c=c+1|0)a.length<=c||null==a[c]?b.push(null):b.push(a[c]);return b}
function sb(a,b){var c=a.indexOf(mb(35));c=0>c?a.length:c;a:{var d=0;for(var e=b.length;0<(d=a.indexOf(b,d))&&d<c;){var f=nb(a,d-1|0);if(38==f||63==f){if((d+e|0)>=a.length)break a;f=nb(a,d+e|0);if(61==f||38==f||35==f)break a}d=d+(e+1)|0}d=-1}if(0>d)return null;e=a.indexOf(mb(38),d);if(0>e||e>c)e=c;d=d+(b.length+1)|0;b=Math.min(a.length,d);a=a.substr(b,Math.min(a.length,Math.max(d,e))-b|0);c=" ";for(b=0;0<=(b=c.indexOf("\\",b));)36==c.charCodeAt(b+1|0)?(d=B(c.substr(0,b|0))+"$",e=b=b+1|0,c=d+B(c.substr(e))):
(d=B(c.substr(0,b|0)),e=b=b+1|0,c=d+B(c.substr(e)));a=a.replace(/\+/g,c);return pb(a,!1)};function F(a,b){this.h=b;for(var c=[],d=!0,e=a.length-1;0<=e;e--){var f=a[e]|0;d&&f==b||(c[e]=f,d=!1)}this.g=c}var tb={};function ub(a){return-128<=a&&128>a?y(tb,a,function(b){return new F([b|0],0>b?-1:0)}):new F([a|0],0>a?-1:0)}function G(a){if(isNaN(a)||!isFinite(a))return H;if(0>a)return I(G(-a));for(var b=[],c=1,d=0;a>=c;d++)b[d]=a/c|0,c*=4294967296;return new F(b,0)}var H=ub(0),J=ub(1),vb=ub(16777216);
function K(a){if(-1==a.h)return-K(I(a));for(var b=0,c=1,d=0;d<a.g.length;d++){var e=L(a,d);b+=(0<=e?e:4294967296+e)*c;c*=4294967296}return b}F.prototype.toString=function(a){a=a||10;if(2>a||36<a)throw Error("radix out of range: "+a);if(M(this))return"0";if(-1==this.h)return"-"+I(this).toString(a);for(var b=G(Math.pow(a,6)),c=this,d="";;){var e=wb(c,b).g;c=N(c,O(e,b));var f=((0<c.g.length?c.g[0]:c.h)>>>0).toString(a);c=e;if(M(c))return f+d;for(;6>f.length;)f="0"+f;d=f+d}};
function L(a,b){return 0>b?0:b<a.g.length?a.g[b]:a.h}function M(a){if(0!=a.h)return!1;for(var b=0;b<a.g.length;b++)if(0!=a.g[b])return!1;return!0}function P(a,b){a=N(a,b);return-1==a.h?-1:M(a)?0:1}function I(a){for(var b=a.g.length,c=[],d=0;d<b;d++)c[d]=~a.g[d];return(new F(c,~a.h)).add(J)}F.prototype.abs=function(){return-1==this.h?I(this):this};
F.prototype.add=function(a){for(var b=Math.max(this.g.length,a.g.length),c=[],d=0,e=0;e<=b;e++){var f=d+(L(this,e)&65535)+(L(a,e)&65535),g=(f>>>16)+(L(this,e)>>>16)+(L(a,e)>>>16);d=g>>>16;f&=65535;g&=65535;c[e]=g<<16|f}return new F(c,c[c.length-1]&-2147483648?-1:0)};function N(a,b){return a.add(I(b))}
function O(a,b){if(M(a)||M(b))return H;if(-1==a.h)return-1==b.h?O(I(a),I(b)):I(O(I(a),b));if(-1==b.h)return I(O(a,I(b)));if(0>P(a,vb)&&0>P(b,vb))return G(K(a)*K(b));for(var c=a.g.length+b.g.length,d=[],e=0;e<2*c;e++)d[e]=0;for(e=0;e<a.g.length;e++)for(var f=0;f<b.g.length;f++){var g=L(a,e)>>>16,k=L(a,e)&65535,t=L(b,f)>>>16,n=L(b,f)&65535;d[2*e+2*f]+=k*n;Q(d,2*e+2*f);d[2*e+2*f+1]+=g*n;Q(d,2*e+2*f+1);d[2*e+2*f+1]+=k*t;Q(d,2*e+2*f+1);d[2*e+2*f+2]+=g*t;Q(d,2*e+2*f+2)}for(e=0;e<c;e++)d[e]=d[2*e+1]<<16|
d[2*e];for(e=c;e<2*c;e++)d[e]=0;return new F(d,0)}function Q(a,b){for(;(a[b]&65535)!=a[b];)a[b+1]+=a[b]>>>16,a[b]&=65535,b++}function S(a,b){this.g=a;this.h=b}
function wb(a,b){if(M(b))throw Error("division by zero");if(M(a))return new S(H,H);if(-1==a.h)return b=wb(I(a),b),new S(I(b.g),I(b.h));if(-1==b.h)return b=wb(a,I(b)),new S(I(b.g),b.h);if(30<a.g.length){if(-1==a.h||-1==b.h)throw Error("slowDivide_ only works with positive integers.");for(var c=J,d=b;0>=P(d,a);)c=xb(c,1),d=xb(d,1);var e=T(c,1),f=T(d,1);d=T(d,2);for(c=T(c,2);!M(d);){var g=f.add(d);0>=P(g,a)&&(e=e.add(c),f=g);d=T(d,1);c=T(c,1)}b=N(a,O(e,b));return new S(e,b)}for(e=H;0<=P(a,b);){c=Math.max(1,
Math.floor(K(a)/K(b)));d=Math.ceil(Math.log(c)/Math.LN2);d=48>=d?1:Math.pow(2,d-48);f=G(c);for(g=O(f,b);-1==g.h||0<P(g,a);)c-=d,f=G(c),g=O(f,b);M(f)&&(f=J);e=e.add(f);a=N(a,g)}return new S(e,a)}F.prototype.and=function(a){for(var b=Math.max(this.g.length,a.g.length),c=[],d=0;d<b;d++)c[d]=L(this,d)&L(a,d);return new F(c,this.h&a.h)};F.prototype.or=function(a){for(var b=Math.max(this.g.length,a.g.length),c=[],d=0;d<b;d++)c[d]=L(this,d)|L(a,d);return new F(c,this.h|a.h)};
F.prototype.xor=function(a){for(var b=Math.max(this.g.length,a.g.length),c=[],d=0;d<b;d++)c[d]=L(this,d)^L(a,d);return new F(c,this.h^a.h)};function xb(a,b){var c=b>>5;b%=32;for(var d=a.g.length+c+(0<b?1:0),e=[],f=0;f<d;f++)e[f]=0<b?L(a,f-c)<<b|L(a,f-c-1)>>>32-b:L(a,f-c);return new F(e,a.h)}function T(a,b){var c=b>>5;b%=32;for(var d=a.g.length-c,e=[],f=0;f<d;f++)e[f]=0<b?L(a,f+c)>>>b|L(a,f+c+1)<<32-b:L(a,f+c);return new F(e,a.h)};N(xb(J,32),J);N(xb(J,128),J);function yb(a){a&&"function"==typeof a.v&&a.v()};function U(){this.h=this.h;this.g=this.g}U.prototype.h=!1;U.prototype.v=function(){this.h||(this.h=!0,this.j())};U.prototype.j=function(){if(this.g)for(;this.g.length;)this.g.shift()()};var zb=!z||9<=Number(bb),Ab=!z||9<=Number(bb),Bb=z&&!y(Za,"9",function(){for(var a=0,b=ua(String(Ya)).split("."),c=ua("9").split("."),d=Math.max(b.length,c.length),e=0;0==a&&e<d;e++){var f=b[e]||"",g=c[e]||"";do{f=/(\d*)(\D*)(.*)/.exec(f)||["","","",""];g=/(\d*)(\D*)(.*)/.exec(g)||["","","",""];if(0==f[0].length&&0==g[0].length)break;a=Ca(0==f[1].length?0:parseInt(f[1],10),0==g[1].length?0:parseInt(g[1],10))||Ca(0==f[2].length,0==g[2].length)||Ca(f[2],g[2]);f=f[3];g=g[3]}while(0==a)}return 0<=a}),
Cb=function(){if(!l.addEventListener||!Object.defineProperty)return!1;var a=!1,b=Object.defineProperty({},"passive",{get:function(){a=!0}});try{l.addEventListener("test",la,b),l.removeEventListener("test",la,b)}catch(c){}return a}();function Db(a,b){this.type=a;this.g=this.target=b;this.defaultPrevented=!1}Db.prototype.h=function(){this.defaultPrevented=!0};function V(a,b){Db.call(this,a?a.type:"");this.relatedTarget=this.g=this.target=null;this.button=this.screenY=this.screenX=this.clientY=this.clientX=0;this.key="";this.metaKey=this.shiftKey=this.altKey=this.ctrlKey=!1;this.state=null;this.pointerId=0;this.pointerType="";this.i=null;if(a){var c=this.type=a.type,d=a.changedTouches&&a.changedTouches.length?a.changedTouches[0]:null;this.target=a.target||a.srcElement;this.g=b;if(b=a.relatedTarget){if(Qa){a:{try{Ma(b.nodeName);var e=!0;break a}catch(f){}e=
!1}e||(b=null)}}else"mouseover"==c?b=a.fromElement:"mouseout"==c&&(b=a.toElement);this.relatedTarget=b;d?(this.clientX=void 0!==d.clientX?d.clientX:d.pageX,this.clientY=void 0!==d.clientY?d.clientY:d.pageY,this.screenX=d.screenX||0,this.screenY=d.screenY||0):(this.clientX=void 0!==a.clientX?a.clientX:a.pageX,this.clientY=void 0!==a.clientY?a.clientY:a.pageY,this.screenX=a.screenX||0,this.screenY=a.screenY||0);this.button=a.button;this.key=a.key||"";this.ctrlKey=a.ctrlKey;this.altKey=a.altKey;this.shiftKey=
a.shiftKey;this.metaKey=a.metaKey;this.pointerId=a.pointerId||0;this.pointerType="string"===typeof a.pointerType?a.pointerType:Eb[a.pointerType]||"";this.state=a.state;this.i=a;a.defaultPrevented&&V.o.h.call(this)}}oa(V,Db);var Fb=[1,4,2],Eb={2:"touch",3:"pen",4:"mouse"};V.prototype.h=function(){V.o.h.call(this);var a=this.i;if(a.preventDefault)a.preventDefault();else if(a.returnValue=!1,Bb)try{if(a.ctrlKey||112<=a.keyCode&&123>=a.keyCode)a.keyCode=-1}catch(b){}};var Gb="closure_listenable_"+(1E6*Math.random()|0);var Hb=0;function Ib(a,b,c,d,e){this.listener=a;this.g=null;this.src=b;this.type=c;this.capture=!!d;this.h=e;this.key=++Hb;this.m=this.s=!1}function Jb(a){a.m=!0;a.listener=null;a.g=null;a.src=null;a.h=null};function Kb(a){this.src=a;this.g={};this.h=0}Kb.prototype.add=function(a,b,c,d,e){var f=a.toString();a=this.g[f];a||(a=this.g[f]=[],this.h++);var g;a:{for(g=0;g<a.length;++g){var k=a[g];if(!k.m&&k.listener==b&&k.capture==!!d&&k.h==e)break a}g=-1}-1<g?(b=a[g],c||(b.s=!1)):(b=new Ib(b,this.src,f,!!d,e),b.s=c,a.push(b));return b};function Lb(a,b){var c=b.type;if(c in a.g){var d=a.g[c],e=qa(d,b),f;(f=0<=e)&&Array.prototype.splice.call(d,e,1);f&&(Jb(b),0==a.g[c].length&&(delete a.g[c],a.h--))}};var Mb="closure_lm_"+(1E6*Math.random()|0),Nb={},Ob=0;function Pb(a,b,c,d,e){if(d&&d.once)return Qb(a,b,c,d,e);if(Array.isArray(b)){for(var f=0;f<b.length;f++)Pb(a,b[f],c,d,e);return null}c=Rb(c);return a&&a[Gb]?a.g.add(String(b),c,!1,ma(d)?!!d.capture:!!d,e):Sb(a,b,c,!1,d,e)}
function Sb(a,b,c,d,e,f){if(!b)throw Error("Invalid event type");var g=ma(e)?!!e.capture:!!e,k=Tb(a);k||(a[Mb]=k=new Kb(a));c=k.add(b,c,d,g,f);if(c.g)return c;d=Ub();c.g=d;d.src=a;d.listener=c;if(a.addEventListener)Cb||(e=g),void 0===e&&(e=!1),a.addEventListener(b.toString(),d,e);else if(a.attachEvent)a.attachEvent(Vb(b.toString()),d);else if(a.addListener&&a.removeListener)a.addListener(d);else throw Error("addEventListener and attachEvent are unavailable.");Ob++;return c}
function Ub(){var a=Wb,b=Ab?function(c){return a.call(b.src,b.listener,c)}:function(c){c=a.call(b.src,b.listener,c);if(!c)return c};return b}function Qb(a,b,c,d,e){if(Array.isArray(b)){for(var f=0;f<b.length;f++)Qb(a,b[f],c,d,e);return null}c=Rb(c);return a&&a[Gb]?a.g.add(String(b),c,!0,ma(d)?!!d.capture:!!d,e):Sb(a,b,c,!0,d,e)}
function Xb(a){if("number"!==typeof a&&a&&!a.m){var b=a.src;if(b&&b[Gb])Lb(b.g,a);else{var c=a.type,d=a.g;b.removeEventListener?b.removeEventListener(c,d,a.capture):b.detachEvent?b.detachEvent(Vb(c),d):b.addListener&&b.removeListener&&b.removeListener(d);Ob--;(c=Tb(b))?(Lb(c,a),0==c.h&&(c.src=null,b[Mb]=null)):Jb(a)}}}function Vb(a){return a in Nb?Nb[a]:Nb[a]="on"+a}
function Yb(a,b,c,d){var e=!0;if(a=Tb(a))if(b=a.g[b.toString()])for(b=b.concat(),a=0;a<b.length;a++){var f=b[a];f&&f.capture==c&&!f.m&&(f=Zb(f,d),e=e&&!1!==f)}return e}function Zb(a,b){var c=a.listener,d=a.h||a.src;a.s&&Xb(a);return c.call(d,b)}
function Wb(a,b){if(a.m)return!0;if(!Ab){if(!b)a:{b=["window","event"];for(var c=l,d=0;d<b.length;d++)if(c=c[b[d]],null==c){b=null;break a}b=c}d=b;b=new V(d,this);c=!0;if(!(0>d.keyCode||void 0!=d.returnValue)){a:{var e=!1;if(0==d.keyCode)try{d.keyCode=-1;break a}catch(g){e=!0}if(e||void 0==d.returnValue)d.returnValue=!0}d=[];for(e=b.g;e;e=e.parentNode)d.push(e);a=a.type;for(e=d.length-1;0<=e;e--){b.g=d[e];var f=Yb(d[e],a,!0,b);c=c&&f}for(e=0;e<d.length;e++)b.g=d[e],f=Yb(d[e],a,!1,b),c=c&&f}return c}return Zb(a,
new V(b,this))}function Tb(a){a=a[Mb];return a instanceof Kb?a:null}var $b="__closure_events_fn_"+(1E9*Math.random()>>>0);function Rb(a){if("function"===typeof a)return a;a[$b]||(a[$b]=function(b){return a.handleEvent(b)});return a[$b]};function W(a){U.call(this);this.l=a;this.i={}}oa(W,U);var ac=[];function bc(a){ra(a.i,function(b,c){this.i.hasOwnProperty(c)&&Xb(b)},a);a.i={}}W.prototype.j=function(){W.o.j.call(this);bc(this)};W.prototype.handleEvent=function(){throw Error("EventHandler.handleEvent not implemented");};function cc(a){U.call(this);this.i=a||document.body;this.l=new W(this);a=na(yb,this.l);this.h?a():(this.g||(this.g=[]),this.g.push(a));a=this.l;var b=this.i,c=this.u,d="click";Array.isArray(d)||(d&&(ac[0]=d.toString()),d=ac);for(var e=0;e<d.length;e++){var f=Pb(b,d[e],c||a.handleEvent,!1,a.l||a);if(!f)break;a.i[f.key]=f}}h(cc,U);
cc.prototype.u=function(a){if(!(!(zb?0==a.i.button:"click"==a.type||a.i.button&Fb[0])||Sa&&a.ctrlKey||a.defaultPrevented))for(var b=a.target;b&&b!=this.i;){if(b.tagName&&"a"==b.tagName.toLowerCase()){var c=b.getAttribute("href")||b.getAttributeNS("http://www.w3.org/1999/xlink","href"),d=c;try{var e=rb(c)[3];var f;if(f="www.google.com"===pb(e,!0)){var g=rb(c)[5];f="/url"===pb(g,!0)}if(f){var k=sb(c,"q");d=k?k:sb(c,"url")}}catch(C){a:{var t=C;if(null!=t){var n=t.A;if(null!=n){C=n;break a}}if(t instanceof
TypeError){var R=n=new kb;R.l=B(t);hb(R);n.g="__noinit__";n.g=t;n.i(new TypeError(n));t=n}else R=n=new E,R.l=B(t),hb(R),n.g="__noinit__",n.g=t,n.i(Error(n)),t=n;C=t}if(!(C instanceof ib))throw C.h;}d=null!=d?d:"";if(c!=d){e=void 0;b={target:"_blank",noreferrer:!0};c=window;d instanceof q?f=d:(f="undefined"!=typeof d.href?d.href:String(d),f instanceof q||(f="object"==typeof f&&f.h?f.g():String(f),Fa.test(f)?f=new q(f,r):(f=String(f),f=f.replace(/(%0A|%0D)/g,""),f=(g=f.match(Ea))&&Da.test(g[1])?new q(f,
r):null)),f=f||Ha);d=b.target||d.target;g=[];for(e in b)switch(e){case "width":case "height":case "top":case "left":g.push(e+"="+b[e]);break;case "target":case "noopener":case "noreferrer":break;default:g.push(e+"="+(b[e]?1:0))}e=g.join(",");if((w("iPhone")&&!w("iPod")&&!w("iPad")||w("iPad")||w("iPod"))&&c.navigator&&c.navigator.standalone&&d&&"_self"!=d)e="A",g=document,e=String(e),"application/xhtml+xml"===g.contentType&&(e=e.toLowerCase()),g=e=g.createElement(e),f=f instanceof q?f:Ga(f),g.href=
u(f),e.setAttribute("target",d),b.noreferrer&&e.setAttribute("rel","noreferrer"),b=document.createEvent("MouseEvent"),b.initMouseEvent("click",!0,!0,c,1),e.dispatchEvent(b);else if(b.noreferrer){if(c=La("",c,d,e),b=u(f),c){Pa&&-1!=b.indexOf(";")&&(b="'"+b.replace(/'/g,"%27")+"'");c.opener=null;Ba.test(b)&&(-1!=b.indexOf("&")&&(b=b.replace(va,"&amp;")),-1!=b.indexOf("<")&&(b=b.replace(wa,"&lt;")),-1!=b.indexOf(">")&&(b=b.replace(xa,"&gt;")),-1!=b.indexOf('"')&&(b=b.replace(ya,"&quot;")),-1!=b.indexOf("'")&&
(b=b.replace(za,"&#39;")),-1!=b.indexOf("\x00")&&(b=b.replace(Aa,"&#0;")));b='<meta name="referrer" content="no-referrer"><meta http-equiv="refresh" content="0; url='+b+'">';if(void 0===m)if(d=null,(e=l.trustedTypes)&&e.createPolicy){try{d=e.createPolicy("goog#html",{createHTML:pa,createScript:pa,createScriptURL:pa})}catch(C){l.console&&l.console.error(C.message)}m=d}else m=d;b=(d=m)?d.createHTML(b):b;b=new x(b,null,Ka);(c=c.document)&&c.write&&(c.write(b instanceof x&&b.constructor===x?b.i:"type_error:SafeHtml"),
c.close())}}else(c=La(f,c,d,e))&&b.noopener&&(c.opener=null);a.h();break}}b=b.parentNode}};function dc(a){new cc(a)}var X=["DOCS_installLinkReferrerSanitizer"],Y=l;X[0]in Y||"undefined"==typeof Y.execScript||Y.execScript("var "+X[0]);for(var Z;X.length&&(Z=X.shift());)X.length||void 0===dc?Y[Z]&&Y[Z]!==Object.prototype[Z]?Y=Y[Z]:Y=Y[Z]={}:Y[Z]=dc;}).call(this);
</script><script type="text/javascript" nonce="">DOCS_installLinkReferrerSanitizer();</script></body></html>